Hi all !
Just a quick update on where we’re at.
At this time we are still at the design phase, as the light client protocol isn’t finalized yet. While we are trying to anticipate on a few decisions, we will still need to be able to communicate with existing nodes in order to implement our use cases.
We have decided to favor a stand-alone module that would meet our immediate needs first (reminder that we are targeting smartwatches as our primary platform). The idea is that we would try and integrate this stand-alone module in the cpp-ethereum code base eventually by working with cpp-ethereum developers. Failing that, we still hope that our code base would at least serve as inspiration for them to add these capabilities (arguably crucial to boost adoption of Ethereum).
We have been in touch with the go-ethereum developers on our “light client protocol” gitter channel, as they are currently the most advanced implementation of the ETH wire sub-protocol. They have been very helpful in explaining some of the subtleties of the sub-protocol and keeping us up-to-date on their progress. I created a quick reference describing the most important changes it brings about.
I had created an initial and partial spec describing a naive approach to our mandate and that didn’t require any of the new PV6{2,3,4} sub-protocol functionalities. However in light of the imminence of their integration in the go-ethereum code base, we decided to scrap it and start a re-design that would leverage these messages instead, thereby greatly simplifying the work on our side (especially in regard to the need to traverse Patricia Merkle Trees – A.K.A. PMT or just “tries” – manually).
We will soon make this re-design available for the community to give feedback on.
See you next week for another update on the progress!
doublethinkco 