Building Liquid: Next Steps

For a young company, nothing is more exciting and vital than announcing the first product. That’s why it was so rewarding for us to be able to include some of our initial customers in the Liquid announcement, which helped us add a real-world dimension to our work. We also greatly appreciated the discussion that followed. We all benefit from and share in the learning process as we advance the state of Bitcoin.

As you can imagine, there are many technical details involved in the construction and operation of Liquid. We plan to release these processes and procedures in an upcoming white paper, which will also include insight into how we apply the technology included in the Elements Alpha open-source release .

Of the many questions posted online regarding what Liquid does and how it works, there were a few particular ones that caught our eye. We provide here a summary of answers to these.

Should you have further questions, we invite you to join the discussion by subscribing to the sidechains mailing list .

Liquid sounds promising, but how does it work?

Liquid is a federated sidechain. This means keys are utilized by a set of functionaries, that the companies who have subscribed to and make use of the network run, for at least two purposes: 1) to sign blocks after incoming bitcoin and other internal transactions are verified, and 2) to sign outgoing transactions back to Bitcoin.

The functionaries extend the Liquid blockchain, as well as authorize fund transfers out of the Liquid network. They perform this function autonomously and without human intervention. The rules they enforce are written in code, just like Bitcoin’s validation rules. To ensure that the rules are followed as written, these functionaries are hosted by multiple independent companies in a K-of-N signature scheme and are hardened against tampering as an additional protective measure.

The K-of-N signature scheme is a security method to make the system “ byzantine secure, ” and the tamper-proofing of the boxes is designed to help ensure that they continue processing transactions as expected (it protects against functionaries conspiring to double-spend Liquid coins and from inappropriately signing out bitcoin). But ultimately the diversity of functionaries is the primary way security is achieved.

Why a Federated Sidechain?

A distributed, federated sidechain makes perfect sense for rapid interchange settlement between Bitcoin companies. Exchanges, brokerages, payment processors, and other power users of the Bitcoin network already use and interact with Bitcoin everyday. These companies, however, are encumbered by the specific need to wait for multiple confirmations on the Bitcoin network when doing business amongst themselves. Liquid alleviates these constraints by providing these companies the ability to rapidly confirm between each other.

The security model of Liquid is indeed different from Bitcoin's. Control is still decentralized, but in a different way. It's distributed to a relatively small number of entities who are Liquid functionaries rather than a large number of miners. This is a tradeoff with both advantages and disadvantages. Rather than trusting miners not to burn some massive amount of resources to rewrite history, Liquid trusts a majority of a small group of known blocksigners who rely on the system functioning. These companies have shared incentives to not go rogue on each other.

Why tamper-resistant hardware?

For this type of federation to be secured, it’s important that the private keys necessary for the multisig to be independently controlled by different entities and also difficult for those entities to make any consensus-related changes. If those entities are different leading companies who each host their own functionary, and a supermajority of functionaries are necessary in a multisig for a block to be considered valid, then this arrangement can be very difficult to compromise. If the keys are generated in a hardened HSM and very difficult to copy without destroying the hardware, this arrangement should be even more difficult to break.

For the system to be undermined, it would require compromise of K of the functionaries, including breaks of the tamper-resistant nodes. Unless all K were compromised simultaneously, there would be a significant time window for the remaining functionaries to act in case of a breach. The system has fail-safes available to them in such an event, up to and including options that would involve halting Liquid and recovering the locked bitcoin that are in it.

There is nothing secret running on this system. Blockstream does not control the functionary hardware, although we do run a single functionary. Everything running on them will be (ideally) auditable, although that is challenging to implement. But the companies hosting the functionaries absolutely have the ability to review and audit what is running inside the node, and verify that it is identical and built exactly from the source code which is also provided in a deterministic fashion. Once the boxes are supplied to the functionaries, we give up any direct control over them, very much by design, to enable distributed operation of Liquid.

Isn’t Liquid just a Multisignature Green-Address Semi-Permissioned Private Chain?

In the original sidechains whitepaper, a sidechain is defined as “a blockchain that validates data from other blockchains.” Liquid is a pegged sidechain. More specifically, it is a federated sidechain, as described in Appendix A of that paper. Many of the design decisions made in Liquid’s creation were prefigured by that appendix (e.g., mutually distrusting, geographically-diverse functionaries, tamper-resistant hardware). As a result of this configuration, bitcoin can be transferred in and out of Liquid via federated consensus without reliance on Blockstream or any central authority.

The use of a multi-sig federat ion of blocksigners is an implementation choice in how Liquid is deployed and secured. It’s not a Dynamic Membership Multiparty Signature (DMMS) merged mined sidechain which would require a soft-fork to Bitcoin. That security configuration is not needed here as the parties involved in the federation are known to each other and act as the multisigners to operate the two-way peg.

This architecture ends up working quite well for Liquid since the parties involved are all known but want to have a distributed trust model that doesn’t require Blockstream or others to have custodianship of their funds or control over the system. This is in stark relief to centralized systems that require a trusted third party.

As an example, a green address approach to solving this problem looks very different from what we’ve built with Liquid. Once coins have been moved onto the Liquid sidechain, they have all the security and double-spending protection that a blockchain provides. A participant that trusts Liquid can safely accept coins sent through Liquid from any other participant. A green address system, by contrast, requires every participant to individually trust every other participant, or, with multisignature, to trust some third party signer to never double-spend coins.

Additionally, Liquid includes Confidential Transactions to maintain the privacy of transaction amounts. Whereas alternative methods of multiparty settlement often leak company-specific transaction information to central parties or other entities, transfers within Liquid retain commercial confidentiality.

Ultimately, we continue to work on the SPV-secured two-way peg originally described in the sidechains whitepaper, but Liquid enables us to bring a product to market that improves the overall security of the Bitcoin ecosystem and puts more business logic at the consensus layer.

Will Liquid support assets other than bitcoin?

The first version of Liquid will not utilize the issued asset capabilities included with our sidechain code. However, future versions of Liquid will support issued assets. The ability to reduce confirmation times for moving assets within the system is an exciting capability to not only the current set of customers but also to many other financial players we’ve met with over the past several months.

Is Liquid Open Source?

Liquid is indeed built with open source software. We expect to reuse the code and architecture for other sidechains. We welcome others to do the same, and hopefully they share their advancements back with the open source community working on Bitcoin.

Aha! So this is why Blockstream wants small blocks!

Liquid has nothing to do with block size or on-chain scaling issues in general. Increasing the block size would not grant near-instant transaction functionality, only more transactions per block. The need for Liquid would still exist even if the block size was 8 GB.

Blockstream has not taken a position on the block size debate, but rather adheres to Bitcoin’s consensus process. Many members of our team participate as independent contributors to Bitcoin development, but i f you’ve been following the discussion, you know even the team here doesn’t always agree with each other. That’s a good thing, in our opinion. We try to hold each other to the same standard of public validation and support as we do our colleagues outside the company.

---

These are exciting times, and we look forward to continued progress and advancement of the protocol and community. Again, if you have other questions or would like to discuss any of the above with us, please join our mailing list and share your thoughts with us there.