Element Block Explorer
Tags: Scalability, Ethereum, JavaScript, Decentralized Identity, Blockchain

Element Block Explorer

Transmute is pleased to introduce a block explorer for Element and Sidetree Full Nodes…with some extra bells and whistles. Transmute Follow Jul 10, 2019 · 4 min read

Check it out here: https://element-did.com/explorer.

We’ve made some serious upgrades to the Element-lib which is the javascript library we use to implement the Element DID. As we mentioned in our last post here, Element is a Sidetree Protocol based DID Method that relies on Ethereum and IPFS. Our implementation is unique in that we provide a JavaScript library that runs in both the browser and node.js, in addition to providing a server-based REST API.

Our first implementation of Element enabled users to anchor their DID directly via a MetaMask-powered DApp thanks to Infura, and also use our “Full Node” to submit operations. Supporting both modes introduced a lot of complexity, and highlighted some scalability issues which we’ve recently fixed.

Using Element.Sidetree

Interfaces might change, but we’ve added a class called “Sidetree” which abstracts a lot of the common functions and interfaces we used in the first version of Element. Here’s how its initialized:

Blockchain and Storage interfaces have not changed (we still support Ethereum and IPFS only).

We have added support for a message bus and database for caching data retrieved from the storage and blockchain interfaces. There 2 new services have opened the door towards some really exciting design patterns like CQRS, and syncing the database from full nodes.

DB: Offline Mode, Caching and Syncing

We’ve added an adapter pattern and a database to Sidetree, and we’re supporting PouchDB / CouchDB and Google Cloud Firestore out of the box.

PouchDB, the JavaScript Database that Syncs!

It enables applications to store data locally while offline, then synchronize it with CouchDB and compatible servers…pouchdb.com

PouchDB is great because it provides a consistent API for both web and node.js and integrates seamlessly with CouchDB for enterprise-scale NoSQL. It’s easy to setup your own CouchDB instance, or host one on a major cloud provider.

We also added support for Google Cloud’s Firestore, because we use Firebase to host most of Element today:

Cloud Firestore | Firebase

Use our flexible, scalable NoSQL cloud database to store and sync data for client- and server-side development.firebase.google.com

Both of these databases have support for offline mode and syncing; right now, we’re not leveraging the sync features, but we do use the IndexDB interface provided by PouchDB to avoid making network requests for Ethereum and IPFS. In the future, we think this offline support will be very useful for anyone building a DID application in an Internet-denied environment, like rural areas or combat zones.

ServiceBus: CQRS and Event Sourcing

We’re huge fans of event sourcing and CQRS. If you are not familiar, check this out:

Command and Query Responsibility Segregation (CQRS) pattern — Cloud Design Patterns

Segregate operations that read data from operations that update data by using separate interfaces.docs.microsoft.com

Now that Element has a message bus built in, there are lots of potential integrations with other event-oriented systems, like OrbitDB, IPFS PubSub, Kafka, and more.

Resolve & Sync

The first version of Element only had a blocking sync method, which downloaded every transaction, anchorFile and batchFile, and then processed all the operations in the correct order. We noticed that starting to take a while even for our small test data.

In the new version we added a fully event-sourced sync method, which uses the message bus / service bus to handle importing operations. In the future, this method can easily be parallelized and distributed, maybe even in a P2P form with something like OrbitDB.

orbitdb/orbit-db

Peer-to-Peer Databases for the Decentralized Web. Contribute to orbitdb/orbit-db development by creating an account on…github.com

When we resolve a DID Document now, we use the db cache and save a lot of network requests. Because sometimes you don’t want your document with eventual consistency, you want it right away, we still support an optimized blocking resolve method, which tries its best to be fast and accurate.

Mnemonic Key System

We’ve added a key system which is particularly useful for testing operations when you want to generate a large number of test actors with various keys for different purposes:

Using mks.getKeyForPurpose(‘primary’, 0) we can easily get a new keypair for a specific purpose, such as recovery. Use-testing complex multi-actor scenarios is much easier this way.

Redux APIs!

We have not pulled them out into a package / module yet, but we have a consistent Redux API for Element whether you are running a Full Node or doing everything in the browser with MetaMask. We use these Redux APIs to power the Block Explorer, and we are still maintaining support for both full and light nodes.

JSON Schemas!

Validation is a precursor to security. We’ve added some JSON Schemas for validating Transactions, Anchor Files, Batch Files and Operations. There’s a big opportunity to do more, especially when thinking about JSON Schema validation for operations.

The Explorer

We put all these new features to together to create 2 block explorers. Our Light Node Block Explorer runs entirely in the browser thanks the MetaMask & Infura for Ethereum and IPFS, and PouchDB. Our Full Node Block Explorer uses the same JavaScript library, also relies on Infura for IPFS and Ethereum, but uses Firebase Cloud Firestore and Firebase Cloud Functions for database and REST API support.

This means you can see what’s going on in the Element network without having to setup MetaMask.

Finally, we also implemented a large number of minor and major fixes — including some attack tests — for various scenarios. The most interesting attack test we have is for the Late Publish Attack, which is the main reason that Sidetree DIDs are not transferable.

We’ve got a bunch of work planned including better integration with the TypeScript codebase currently powering ION. The Transmute team is excited to keep pushing Element forward!