Developer’s Update: Verification methods
May has been a flawless month from the developers’ side: not only they were able to quickly solve most of the initial obstacles, but they really pushed their foot on the accelerator and managed to complete important milestones on our agenda.
Arguably, one of the major accomplishments is the possibility to launch Lition sidechains using Ethereum mainnet identities. All the scripts have been modified, so that users, now, can pass their Ethereum private keys during node creation. This process is then used to generate the node identity and authenticate it against the sidechain network. Having one set of identities greatly simplifies authorization, a “must” especially for private sidechains.
To allow this, we have deployed a test environment consisting of two nodes and Ropsten acting as Ethereum mainnet. On the latter, the initial version of registry and notary contract has been deployed, supported with a test version of LIT tokens.
Currently, our developers are mainly focusing on three areas.
Development of registry and notary smart contracts
Here we are working to have one simple, secure and fast entry point on the Ethereum network for all Lition’s operations, from blockchain registry to mining rewards calculation. In this regard, it was necessary to deploy a second version of contract, as Geth’s golang binding generation is way behind Solidity. Notary method requires extensive amounts of structured data (see our previous post) and using the new ABI model would greatly reduce its complexity.
Development of a secure and publicly verifiable notary protocol
Since we are planning to support different consensus mechanisms on our sidechains, such protocol will need to be on the one side universal and extensible on the other. Additionally, it must be light enough to be evaluable by Ethereum smart contract.
So far this is our goal for the shorter-term. Once the protocol design will be finalized, it will need to be implemented in both notary and registry smart contracts, as well as in the node manager. While our testnet is still running on the RAFT consensus, the initial version of the protocol is relying on istanbul BFT, as this protocol and its existing tools provide some useful insights about miners involvement in block generation:
./build/bin/istanbul extra decode — extradata 0x0000000000000000000000000000000000000000000000000000000000000000f89af85494475cc98b5521ab2a1335683e7567c8048bfe79ed9407d8299de61faed3686ba4c4e6c3b9083d7e2371944fe035ce99af680d89e2c4d73aca01dbfc1bd2fd94dc421209441a754f79c4a4ecd2b49c935aad0312b8410000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c0OUTPUT:
vanity: 0x0000000000000000000000000000000000000000000000000000000000000000
validator: 0x475cc98b5521ab2a1335683e7567c8048bfe79ed
validator: 0x07d8299de61faed3686ba4c4e6c3b9083d7e2371
validator: 0x4fe035ce99af680d89e2c4d73aca01dbfc1bd2fd
validator: 0xdc421209441a754f79c4a4ecd2b49c935aad0312
seal: 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sidechain integration
This component integrates the sidechains with the registry and notary contracts on the Ethereum Main Network. It is located in the so called “node manager”, a local entity that lies next to a blockchain daemon and provide multiple integration functions. The node manager is responsible for the checking of information about allowed sidechain network participants. Moreover, it authenticates and authorizes new join requests.
As anticipated before, working at this pace we won’t have any problem respecting our timeline and meet our obligations. The final product is yet to be developed, but, given the previous month’s results, we are confident our team of developers will soon deliver to the public a functioning version which will live up to our users’ expectations.
