Witnet Sprint Review #35 + DEMOS (Apr 3rd 2020)

This is Witnet Sprint Review for sprint #35 The goals for this sprint were: completing the protocol — basically the last big feature that was missing, which was “collaterals”; In Sheikah, completing the claiming process for the people that have the right to have tokens assigned in the token generation event of Witnet; for them to claim their tokens; And in the smart contracts, finishing the bridging contracts and freezing all that codebase. The main focus for Sheikah during this sprint has been working on implementing the claiming process. Now in the claiming process the disclaimers are signed and aggregated to file that will be sent to the Witnet Foundation. We have implemented the vesting step that we will show in a later demo. We disabled some development features in production such as “back and forward” or “browser shortcuts”.

01:06 - On the other hand, we have been implementing our own file upload component to avoid a trick on the Elemement UI own component and get a smoother behavior in the claiming process. In the Witnet node we have been fixing some bugs related to bucketing and the peering between the nodes. Also we improved the consensus forming among the peers to reduce the fork problems, and also we prepared and coordinated the Testnet 7.3 that is currently working as we released it yesterday. And also well, for the Testnet 8, which is in another branch now, we implemented the “UTXO coin age” that provides information about when UTXOs were created, as this is a requirement for collaterals.

02:03 - And also implemented the collaterals for data request mining — as specified in the WIP-0002. The Witnet nodes now risk not also reputation but also a quantity of Wits as required by the data requestor and that produces an improvement against “Sybil attacks”. So, the release is expected for the next sprint. With respect to the smart contracts, last sprint we finished the “Smart Proxy” for the block relay, but we had pending the “Smart Proxy” for the Witnet Requests Board (WRB) — which we completed this sprint — so basically now even if we upgrade the WRB we don’t lose the state of the upgraded contract. Then we also finished our internal code review of all repositories including the new layout of the proxy contracts.

03:00 - We also deployed all the contracts in both Görli and Rinkeby and perform an end-to-end tested to see that all the changes we applied these last two sprints didn’t break anything — which we are glad to announce that they didn’t. We also created a gold price feed using four different sources and it’s now live on both Görli and Rinkeby, so I encourage you to try it. Not the gold price but Mario will show an example later about the Bitcoin price, but it’s essentially the same mechanism. And we also are glad to announce that we started the external audit. So with communications and outreach, we now have a Phase 1 scoreboard that has gone up, which has been great and encouraging healthy competition between the Phase 1 participants as well as just making more clear about how much rewards each participant will be getting.

03:46 - We’ve made a lot of progress on the Phase 2 of the Testnet Incentive Program plan, it’s really starting to take shape. We’re aiming to release the details of this in mid April. It is exciting stuff; it seems that we’d made a lot of headroom in the last week. As Gorka said, we’ve now got a gold to Euro price feed (which Mario will be going through). We’ve sent it to a potential collaborative partner so we’re going to here back from them to see if they are interested in using it.

04:13 - We have an EIP public meeting with ADO — the “Alliance of Decentralized Oracles” — late in April, which all of the community is welcome to join us on. We’ll be holding it on Zoom and I will go over more details I’ll be releasing on Twitter and on Telegram. Tellor and Witnet are leading the charge on this and it’s going to be exciting. And we’ve done a Phase 1 survey to collect details on what particular interests the community has in getting involved in the next month or so. We had various projects and tools proposed and started to be in development within the community, so we have a big month ahead with a lots of announcements.

04:53 - Special shout out to Bertrand for his advice, engagement and codebase contributions; vbstreetz for deploying the Ethereum smart contracts by himself; Igor for his contributions to documentation; parody_bit for his codebase help, DeHero for his help within the community; and Jaroslav for his interest and enthusiasm with regards to P2P bucketing. Regarding the Sprint, we just wanted to give kudos to the whole team because we managed to have our personal record in terms of the user story points. We managed to complete almost 240 story points and to finished almost everything we committed to, so great kudos for everyone and it seems like we did a great job. Regarding the impediments nothing but coronovirus because we changed our culture — the way we work; and at the same time we also wanted to express all the problems we always have regarding the Solidity contracts because they depend on each other and every time we do a change in one of them we have to follow the chain or the cascade towards all of them, so it’s a tedious task, you know. And finally just a quick peek, we had a tentative roadmap regarding the audits.

06:10 - During this sprint we were supposed to upgrade the Solidity version — which we did the last sprint — we did also the internal audit and everything has been done. During the sprint the external audit already began, so now we are in continuous communications with them regarding clarifications and helping them and during the next weeks we expect to have more ongoing questions and potential fixes. Ok, and now the interesting part, we will do three demos: one is on price feeds (the reference implementation we did for a Bitcoin price) and we’re going to see how you can interact with it at Etherscan. Then we’ll have another one about the wallet initial synchronization; and the claiming process in Sheikah. Let’s start with the first one. So what we have here is that we deployed a contract that is called “PriceFeed” and is a simple contract that has two public functions (we can see it here) in which you can always request an update on the Bitcoin price by providing an amount that is going to be the reward for completing this price feed functionality.

07:30 - Ok, first I have to connect to my MetaMask. This contract is deployed on Görli so this is fake Eth. Maybe a can zoom it a little bit. Ok, so once you request the update and you interact with Etherscan, you can send it and now we have just to wait until the transaction is accepted. You have to refresh. Here we can see one transaction that was the contract creation, the second one was the requesting a Bitcoin price feed, you have to wait until this request is resolved by Witnet, we’ll see it later. And once this request has been resolved, you can request the “complete”, which means writing the message inside.

08:15 - Something that will happen behind the curtains, maybe we can also go to the slides, the request update and complete update, and what happens behind the curtains is that the user interacts with a Solidity consumer contract (the “PriceFeed” I just showed) and what will be happening is that the request is going to be built and is going to be sent to a “bulleting board” that is called the Witnet Requests Board (WRB) and at that moment some bridge will detect that there is a new request there, they will take it and they will relay it towards the Witnet Decentralized Oracle Network. Then in Witnet, this request will be executed and completed, and once the result is available in our blockchain the result will be relayed back to the WRB. When the result is already in the WRB then it’s supposed to be ready for the user to complete the update. This is the WRB and we transaction — I think it’s this one — this transaction is the one in which the bridge node checks if he can claim some data request within the WRB. Once he does that, then he can report once this transaction, this data request is included in Witnet, he sends back a data request inclusion saying “ok, this data request is already in Witnet” so that he can get some reward.

09:43 - After this data request is resolved, which takes around 4 epochs that right now in testnet is 45 seconds (it means at least three minutes) a bridge node can report back, call “reportResult()” with the result, back to the WRB. In that moment in time is when the PriceFeed contract is ready to complete the Bitcoin price update. Then in this contract we can click on “write completeUpdate()” because until now the price amount is not yet written in the contract and when we do that what we do is make this contract ask the WRB contract to write the amount of the Bitcoin price inside the contract. Let’s see if the transaction has been accepted or not. Ok, it says “pending = false”, so it’s not pending, we can already see the Bitcoin price and the transaction should appear here, ok, 22 seconds ago. And that’s it.

10:48 - So what we saw here is that the result was ready, the bridge relayed it back to the WRB and once it is there the user through the Solidity consumer contract can request the “completeUpdate()”, which means copying back the Bitcoin price into the Solidity consumer contract. I think the next one is the “Wallet Initial Synchronization”. So, what’s this thing about “Wallet Initial Synchronization”? Right now when you have Sheikah wallet or any client for a Witnet wallet you could perfectly run the wallet and if you received a transaction you’d get notified in real time and your balance would be updated. That’s obviously the way it must work. But on thing that the Witnet wallet was not capable yet was basically catching up while being down, while being offline or while it’s not running so that if you have received transactions while the wallet component — which is a service that is supposed to be running ²⁴⁄₇ — but just in case it goes down or you are not running it all the time because of resource limits in your computer or whatever; the idea is that it needs to catch up with the rest of the network. In the same way if you import a master key for a wallet that already existed and already had transactions in it, the wallet needs to be able to discover the old transactions and import all of that into the state of the wallet and show that in your client: Sheikah or whatever. So, that’s what we’ll be seeing now.

12:41 - I will unlock this wallet that I created before, and as soon as I click on “Unlock” we will see that it will download every block from the Witnet block chain that happened after the last time I opened this same wallet; it will read all the transactions from it and see if there’s something new to show to the user. So if I do unlock, you will see that it’s indexing all the transactions from the last blocks and it says that it is now synced to latest beacon (as you can see here). In the same fashion, if I close the session and create a new wallet, seed phrase and so on, ok, what we will see is that it’s syncing, it’s trying to synchronize from the beginning, from the “genesis block” in the chain so it will download every block and check if there are transactions that are relevant to the addresses of this specific account and wallet and so on. It takes a while for sure, but is not storing the blocks or anything, it’s just indexing the transactions locally so that you can access them at any time and also discovering all the addresses in the wallet and so on: just as you may expect. It’s finished now. You can see that this wallet is marked as synced to this block height which is the current one and obviously if we close the session and enter again the synchronization will be immediate because no block happened between the last time we synced and now.

14:28 - You see that the difference in the chain is empty — there were no blocks in between. Ok, one other thing is the main point of this, which is: what happens if I stop the wallet component, the wallet back-end? You will see that Sheikah complains about no wallet back-end existing, as there needs to be a wallet back-end running for Sheikah to interact with the Witnet network because this wallet component sits between the Witnet node and Sheikah or any other client facing to the user. If I run now the node and reload Sheikah and so on and unlock, it would catch up with the last blocks, but of course there’s nothing interesting to show there. So one thing that I want to try to show here: let’s get an address for this wallet, let’s generate an address, do “Receive”, copy this address and I will send some funds while this wallet is locked to see if it’s able to catch it later. So what I will be doing is stopping the wallet as I said before, and then I will send from my own node, I will send some funds to that.

15:49 - I will use the “send” method form the node’s CLI. I need to specify the address of the recipient, then I need to say how much through “value”, I will be sending a lot of “9”s and also the fee for the miner: this time I want to be generous. Let’s see, ok, the transaction looks like it was well-formed so it will be sent to the network and as soon as there’s a block it should catch it. We can already launch the wallet because if I don’t unlock the wallet in Sheikah you cannot actually sync the wallet because it needs to be unlocked because it’s totally encrypted in the storage and it cannot write into the wallet state without it being unlocked. Here you see it’s already discovering new blocks but it cannot actually know if there’s something in that block that is relevant to my wallet, because the wallet is totally locked and we don’t know the addresses, we don’t now a thing about it.

17:10 - So as soon as there are a couple of blocks, I assume that my transaction is inside one of those, but we can make sure maybe using the node. Maybe we can do “cargo run node getBalance” and like that, we can see that that transaction is confirmed and it received the funds. So just let’s go back to having here the wallet. In Sheikah we can unlock this and what we are expecting is Sheikah to discover the new funds and the new transaction thanks to the wallet back-end that will be indexing it. We can see that it is syncing, ok! Here is our balance and here is the transaction, just as we expected. Cool.

18:06 - Well, the first thing that maybe you are seeing is that we have applied a completely new design: now Sheikah is “more purple”. This is the “claiming process” that all the people that participated in the initial sale will have to go through to claim their tokens. When they download Sheikah and receive a “participant proof file” from Witnet Foundation (WF), they will see something like this. The first step is claiming process information where we will be displaying all the information about the process, then you have to import the file that WF has sent to you. Here’s an example of this file, and we can see, here will be my name, and the information about the participation that we did in the sale and the tokens according to that amount.

19:11 - We also can see the dates in which the funds will be unlocking and the next step is to create your wallet. For creating your wallet, you have to accept the disclaimers and these disclaimers will be signed and later aggregated into a file that you’ll need to send to WF. Well, we copy the seed phrase, confirm, add a password, and now Sheikah will generate new addresses according to the number of Wits that correspond to your [claiming] process and automatically generates the file that has to be sent to WF. Export the file here and the final step to send this file to the genesis(at)witnet.foundation so your funds are aggregated to the initial block.

20:13 - I think I can show you the shape or the structure of the file, I can share this. This is the structure of the file that Sheikah generates that contains the email address, the name, and the most important thing: the addresses that Sheikah has generated to store your funds and the disclaimers signed that you had to accept to go through this process. And that’s it. And to finish the sprint review, some memes! [Chuckles] [Laughs] Spanish memes. That’s me in the middle one. [Laughs] [Laughs] Bertrand’s nodes. .