- Click here if you just want to read the Paper -
In the last two posts of this series, we first introduced the governance issues in PKI and then the circular dependency between establishing trust in PKI certificates and establishing the current time on a connected device.
So let’s break that circular dependency between time and trust. The difference between trusting a person/an entity and trusting data is key here. How can we establish trust in the data, specifically in the time information, without trusting the individual messenger of this data? This is, in fact, leads to the same problem that Satoshi Nakamoto set out to solve with bitcoin the first blockchain network. The term blockchain has become rather muddy, but by convention, the property we’re talking about is the trustless blockchain. Creating a public consensus of the current state of facts without trusting any individual.
Conveniently for our quest to getting the current time without trusting anyone both trustless blockchains Bitcoin and Ethereum carry a timestamp in their block. So it seems as easy as that - if we can establish a connection to the blockchain consensus of either of these networks - we have established the current time - trustless! But…
“Resource-Constrained Devices”
When HTC announced that their new Handheld Exodus 1s will be running a full Bitcoin node that immediately raised eyebrows. Running a full Bitcoin node at this time requires ~200gb of storage plenty of ram and constant data bandwidth of ~140mb a day. For Ethereum the situation is similar:
| Node Type | Trust Model | Sync Bandwidth | Sync Duration |
|---|---|---|---|
| geth --syncmode=full | Decentralized | ~400GB | days |
| geth --syncmode=fast | Decentralized | ~130GB | hours |
| geth --syncmode=light | Decentralized | ~1.2GB | minutes |
For just getting the current time loading 1.2gb of blockchain data seems a bit hefty. Also, we’re working mostly on low-end chips for small IoT products, such as an ESP32, TI CC3220, or a LinkIt 7697. The RAM budget in this class is ~200kb and storage ~1mb. So we needed a different solution. One that would also withstand Man-In-The-Middle attacks.
Enter BlockQuick
Just 20kb to validate the blockchain.
We started developing BlockQuick with these goals in mind. BlockQuick is a super-light-client, meaning the amount of data that it needs to fetch from the blockchain is sublinear to the total size of the blockchain. BlockQuick is using a consensus-based reputation scheme to accept blocks. During development, Benedikt Bünz released FlyClient, another super-light-client which inspired a better solution to do Block-Inclusion-Proofs in BlockQuick. To our knowledge these two forms currently the only two entrants in the new class of super-light-clients for decentralized blockchain validation on resource-constrained devices.
| Node Type | Eclipse Resistant | Sync Bandwidth | Sync Duration |
|---|---|---|---|
| FlyClient | No | ~500kb | seconds |
| BlockQuick | Yes | ~20kb | sub-seconds |
With the current BlockQuick implementation we can finally reach our trivial goal of breaking the circular dependency with a 20kb handshake to get a relatively accurate time. But this has also brought more opportunities to leverage blockchain from small devices.
Currently, we’re working on a branch of Ethereum that implements BlockQuick and are active in Ethereums constrained resource client ring. Now that the hard part is done, we’re working to solve the followup problem for light clients.
Why Should an economic Miner waste CPU resources for answering light client requests?
If this made you curious follow us on Twitter or feel free to reach out to us on Telegram.
Sources
https://www.engadget.com/2019/05/11/htc-exodus-1s-blockchain-phone-node/
https://labs.mediatek.com/en/platform/linkit-7697
http://www.ti.com/product/CC3220S
https://www.espressif.com/en/products/hardware/esp32/overview