witnet-rust
witnet-rust copied to clipboard
Open source Rust implementation of the Witnet decentralized oracle protocol, including full node and wallet backend 👁️🦀
An alternative synchronization method has been proposed for the wallet component, such that instead of asking a node for all blocks in the chain and checking all transactions for addresses...
In the same way that #2377 allows using the node's JSON-RPC methods over HTTP, TCP and Websockets, the Wallet component should also support multiple transports for convenience and ease of...
I know @drcpu-github faced this issue in which nodes that are fast-synced from snapshots will rewind to genesis if there is a rollback, especially that happens right after the node...
Radon scripting at the retrieval phase has shown to be highly effective on crawling and extracting concrete data from both HTTP/GET and HTTP/POST sources. It's this kind of radon scripting...
Data requests with RADType::Unknown sources are wrongly accepted into blocks since WIP0020. Example transaction: 38d8cf497622082fa8fd4e89831641834918a99472b722310d60664046a29883 ``` {"jsonrpc":"2.0","result":{"blockEpoch":1544550,"blockHash":"3a077d6b4064524afa01e1b8781cfb059693653d5138734b0ffef27253a24bc9","confirmed":true,"transaction":{"DataRequest":{"body":{"dr_output":{"collateral":10000000000,"commit_and_reveal_fee":1000,"data_request":{"aggregate":{"filters":[{"args":[251,63,241,153,153,153,153,153,154],"op":5}],"reducer":3},"retrieve":[{"kind":"Unknown","script":[130,24,119,130,24,101,101,108,105,107,101,115],"url":"https://api-middlewares.vercel.app/api/twitter/tweets/0"}],"tally":{"filters":[{"args":[251,63,241,153,153,153,153,153,154],"op":5}],"reducer":3},"time_lock":1630669134},"min_consensus_percentage":51,"witness_reward":1000000,"witnesses":100},"inputs":[{"output_pointer":"7cc0415818cd633916c4a3d3ea097d13e04973a8be010baea39244d83fa6d6bc:0"}],"outputs":[{"pkh":"wit1c0ucz2u9hwgqflkn4xjeyxtla9tqp0sderzkjr","time_lock":0,"value":2166708072}]},"signatures":[{"public_key":{"bytes":[176,193,72,220,165,255,123,112,10,173,38,116,83,157,103,237,213,54,147,62,72,34,100,153,202,212,153,241,200,151,13,32],"compressed":2},"signature":{"Secp256k1":{"der":[48,69,2,33,0,144,199,29,249,135,183,74,33,30,61,204,36,30,87,98,167,21,127,197,46,46,14,71,113,28,140,180,187,140,181,170,26,2,32,52,178,190,191,36,97,187,28,26,178,118,166,244,232,234,177,76,247,204,102,75,70,54,251,121,21,52,208,151,229,70,15]}}}]}},"weight":64009},"id":"1"} ``` Summary of the behavior: * Before WIP0019: RADType::Unknown are accepted, and treated...
New **Map** operators: - ***MapMap***: same as *ArrayMap*, but iterating on maps. - ***MapFilter***: same as *ArrayFilter*, but iterating on maps. - ***MapAlter***: expecting two parameters: "key" and SUBSCRIPT; it...
For instance: `{"data": 122637770461000000000}`
Issue #2310 describes a radon script whose result cannot be encoded. If that happens, nodes will not commit any value and the data request will probably resolve with "insufficient commits"...
During the recent rollbacks that prompted the release of version 1.5.4, we noticed that some nodes were trying to count votes for superblocks with an odd index, while other nodes...
When tally execution panics, the data request is resolved as "RadError::Unknown". I would expect a similar behavior if the retrieval or aggregation scripts panic, but that's not the case. Instead...