Maximizing Sidetree Velocity
If you don’t know about Sidetree yet, you can read about Transmute’s implementation Element, or you can dive into the protocol itself.
At Transmute, we are not decentralization purists. We believe that emerging tech, and especially DLT / blockchain, has the most immediate value if it augments and extends legacy centralized systems, workflows, and data. This pragmatic philosophy has consequences as we transition from protocols on paper to concrete implementations that are secure and flexible enough for immediate adoption.
Our team’s approach to building Element — our Open Source Ethereum and IPFS implementation of Sidetree — illustrates this balanced approach. While developing the protocol, we realized that Sidetree does not require a server: everything can be done in a browser.
Not relying on a server (full node) has some advantages and disadvantages:
Pros:
- Trustless: Users can CRUD (Create / Read / Update / Delete) for themselves by paying for operations that are relevant to them (assuming you run your own Ethereum and IPFS nodes and don’t use a service like Infura).
- Less resources: The solution runs in browser and there is no need to pay for hosting or a standalone suite of services on your own computer.
- Separation of concerns: Reduced reliance on a server (full node) helps us draw a clear line between protocol operations, functions and data structures on one hand, and transport, batching and API design on the other.
Cons:
- Cost for ledger activity: Without batching operations with many other users, you pay a higher cost for your own operations.
- Performance: While aiming to support in-browser nodes keeps engineers honest, a web client will never out-perform a scalable set of microservices.
- Multi-client support: A REST API can be consumed by many different kinds of clients in different languages. A javascript library does not have this kind of flexibility.
As we considered these tradeoffs, we realized we could have our cake and eat it too by supporting both full and light node options.
Our Sidetree protocol library element-lib helps us rapidly adapt protocol changes to our UI, element-app, and our API, element-api. This means we can power the client-side and server-side Sidetree implementations from the same library, reduce redundant code, and allow us to focus on developing the right interfaces for both scenarios.
Additionally, since IPFS is used to store Sidetree operations, why not use it to serve Sidetree clients? An IPFS-hosted web app can talk to a centralized or local web server, so it’s also possible to have it talk directly to the ledger and IPFS. Performance will certainly be an issue, but we think that the best way of keeping Sidetree as fast as possible is to encourage using it in resource-constrained environments like web browsers..
Another reason for our approach is that for a protocol to be truly great, it must have multiple, interoperable implementations in different languages. We want to support the shared Typescript codebase that currently powers ION — Microsoft’s Bitcoin implementation of Sidetree — but we also think having an implementation that leverages the Ethereum ecosystem and DApp philosophy will attract different kinds of developers. We ultimately believe this diversity is a key factor in developing resilient and secure systems.
