Achieving the Enterprise Blockchain Big Three

By Katie Clay

Symbiont is pushing the boundaries of blockchain technology, bringing it into the mainstream for enterprises. Each client of ours, whether it’s a big bank or another type of financial institution, will run an instance of our platform (we call these nodes). From there, each node transacts with each other in a more streamlined way than current methods. As a solutions engineer on the team, it’s exciting to be part of the organization leading the financial services infrastructure revolution and defining how enterprise blockchain platforms should be built.

Consistency, Confidentiality, and Decentralization

An enterprise blockchain model ideally should maintain consistency, confidentiality, and decentralization among all nodes in a given network. Any two of these attributes are tricky to support; finding the intersection of all three is a downright conundrum. Public blockchains are consistent and decentralized at the obvious cost of confidentiality. Many permissioned blockchains, while introducing confidentiality, must also introduce some degree of centralization (be it through operators, notaries, and the like) to verify consistency. How is it possible to integrate three qualities with seemingly opposing characteristics?

Secure Channels

Enter: secure channels. They work like this:

1. Every node receives an encrypted value for every single transaction that takes place on the network.
2. Users can become part of a group-or channel — where the transactions are encrypted with a unique key for that channel.
3. When members of a particular channel create a transaction, only members from that same channel have the key to decrypt the encrypted value.

All three enterprise blockchain virtues are preserved: consistency is achieved by each node having identical transaction logs, confidentiality is maintained through encryption, and decentralization is accomplished through not requiring centralized verification. Any potential eavesdropping node trying to peek at transactions will only ever see encrypted gibberish, eliminating the possibility of users — individuals authorized to perform transactions on a node — “hacking” their way in. Secure channels provide everything expected of a good permissioned blockchain.

Now that we know more about secure channels, that begs the question: how do users interact with them?

The user who creates a secure channel is automatically added to said channel, and also becomes that channel’s owner. Once a member of a secure channel, the user can invite others to the channel by sending them the key needed to encrypt/decrypt transactions for that channel. Once a key has been given, it can never be taken away; any users with the key can use it from that moment until the end of time. This could pose a problem if there are members you no longer want to share information with.

Owners of a channel can remedy this by changing (we call it rotating) the key necessary to encrypt/decrypt transactions in that channel. The owner who rotates the key is the only one who automatically receives the new key. Members of the original channel she wants to retain will need to be sent the new key again (or she can relish in her newfound solitude). Once keys are sent to the desired members (if any), knowledge sharing can resume. Owners also can elect to create/remove other owners in the channel, granting/eliminating the ability to rotate keys.

Implications

So, now that we know a bit more about our privacy model, why do we care?

Great question! Channels inform a huge part of how smart contracts are written. Defining transaction functionality is as straightforward as a standard coding project. In fact, many transactions can be written into the PUBLIC channel, which is our keyword for the secure channel everyone in the network is automatically part of. However, introducing channels also means introducing a bevy of security implications to think about:

• What transactions need (or don’t need) to be restricted to channels?
• Are there users that should be added to certain channels from the get-go? How do you handle sending out keys to them?
• When is it appropriate to add other owners to the channel?
• What if information written into one channel is necessary for computations in another? (This is a blog post for another day.)
• Should only certain members of a channel be allowed to write a transaction versus just read channel data? How do you lock down that functionality to just those members?
• And the list goes on!

With all of these considerations, secure channels are not only a fantastic security solution. They force you to elevate your coding and planning games, making you a better engineer in the process.

— — —

Shoutout to the wonderful Sarah Lee, Anna Savarin, and Nathan Wells for not only helping me with this blog, but for helping pave the way for women like me in this field! To all the women building something exciting, happy International Women’s Day!