Over the past few months, Chorus One has led the Liquid Staking Working Group to investigate approaches and implications of tokenized stake in Proof-of-Stake networks. Today, we are proud to share the final report that we put together as part of this Interchain Foundation research project.
The Liquid Staking Research Report seeks to lay the foundation for a broader discussion around the trajectory of Proof-of-Stake and the role of staking assets in the emerging decentralized financial economy. The 88-page report covers five main topics:
Staking requires users to lock their assets to earn rewards for securing the underlying network. The way most current protocols are designed, this means the burgeoning decentralized finance ecosystem is not accessible to staking users. In addition, protocols enforce waiting periods for users wanting to withdraw their stake. The report goes into why these restrictions exist and what kind of costs they imply to users.
By pooling staking assets of their customers, cryptocurrency exchanges can alleviate some of the costs for staking end users. Through clever liquidity management and by allowing users to simultaneously stake and access services such as (margin) trading on their centralized platforms, exchanges are able to offer superior products to token holders seeking to participate in staking. The report illustrates this trend and its potentially detrimental second order effects to Proof-of-Stake.
The core goal of the report is to examine alternative staking models that could allow non-custodial staking to rival the centralized custodial experience. To do this, we define liquid staking as protocols that tokenize stake in some form. Tokenized stake, sometimes also referred to as staking derivatives, could allow staking users to access decentralized finance helping them to manage their positions in a flexible and non-custodial manner. The report differentiates between native, non-native, custodial, and synthetic approaches to liquid staking.
The report takes a look at the high-level risks and benefits of liquid staking taking into account the user, network, and legal perspective. We discuss everything from potentially interesting staking-related financial products, over the effects on network centralization and governance, to the regulatory implications of different approaches.
The final part of the report describes proposed designs within the space going into potential benefits and weaknesses of models brought forth by project teams like Rocket Pool, StakerDAO, Stake DAO, Acala and others.
Download the full research report here:
https://mirror.chorus.one/liquid-staking-report.pdf
We’d like to thank everyone that provided us with feedback or contributed to this research in any other way. We are looking forward to continuing to push forward the decentralized Proof-of-Stake ecosystem. Visit our website at https://chorus.one to learn more about our services.
Chorus One is providing staking services and developing cross-chain communication technologies for Proof-of-Stake blockchain networks.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
The Interchain Foundation (ICF) is a Swiss foundation, founded in 2017, with the mission of promoting and advancing research and development in open and decentralized networks, with a particular focus on the Cosmos Network.
Website: https://interchain.io
Twitter: https://twitter.com/interchain_io
The Liquid Staking Working Group is committed to advancing the state of the art in staking economics and understanding the broader impact of advanced staking protocols. Join the official Telegram to participate in the discussion.The Liquid Staking Working Group has been hosting meetings in which implementing teams and other relevant projects presented their work. Recordings of these meetings during which representatives of companies like Terra, Matic, UMA, and Unslashed presented can be found on the Chorus One YouTube channel.
Originally published at https://blog.chorus.one on June 16, 2020.
Chorus One has received a grant by the Web3 Foundation to develop parts of a bridge that will enable Substrate and Cosmos SDK-based blockchains to interoperate as part of the fifth grant cohort.
Such interoperability will allow, for example, a user on a Cosmos SDK blockchain to move TerraUSD coins to Substrate chains to take advantage of applications in the Polkadot ecosystem.
A core piece of Chorus One’s vision is the ability to freely transfer value and information across sovereign blockchain networks and applications. The Polkadot and Cosmos ecosystems have both been at the forefront of cross-chain interoperability.
We are excited to contribute to bridging these two ecosystems with this initial project that will enable Cosmos SDK blockchains to keep track of consensus updates on Substrate-based networks.
Polkadot combines the versatility of heterogeneous blockchains with the security and convenience of a single security pool and validator set. This is one of the most daring and promising visions of the blockchain space and could unleash unparalleled innovation. The Polkadot ecosystem is consistently shipping great software to advance that vision. We are incredibly excited to help bridge the flourishing Polkadot and Cosmos communities.
Brian Fabian Crain, CEO of Chorus One
A Substrate light client that’s compatible with the Cosmos SDK is a great first step towards bridging the Polkadot and Cosmos ecosystems. We’re excited to see the results of this work and eventually a complete bridge between both networks.
Dieter Fishbein, Head of Ecosystem Development at Web3 Foundation
This grant-funded project lays the groundwork for a bridge between Polkadot and Cosmos. The current project code consists of three parts: a relayer implementation that allows necessary information to pass between two blockchains, a Substrate-IBC module for the Cosmos SDK that is geared towards handling Substrate data, and a Substrate client consisting of WebAssembly bytecode to verify BABE and GRANDPA consensus information on Cosmos chains. In order to have a fully functional bridge, a second follow-on project that allows Substrate chains to validate Tendermint messages is required.
Our WebAssembly Light Client design for Substrate on Cosmos SDK can be extended to support any other blockchains whose light client logic is compile-able to Wasm. One key advantage of the design is the ability to upgrade the Substrate light client, which is derived from the canonical Rust implementation, on Cosmos SDK chains without requiring a full governance process and hard fork for each upgrade. Additionally, the design may be able to easily handle consensus algorithms and allow them to interoperate with the Cosmos ecosystem via IBC. Find the full details and technical description of our approach here.
We are excited to contribute to realizing a world of interconnected blockchains. If you are interested in working with us on this, reach out to us via the channels linked below.
Chorus One is operating validation infrastructure and building tools to advance the Proof-of-Stake ecosystem.
We will offer staking on Polkadot when the network goes live. You will be able to support our work and earn staking rewards by nominating our validators with your DOTs.
Website: https://chorus.one
Anthem Staking Platform: https://anthem.chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Image on cover art by Aaron Burden on Unsplash.
Originally published at https://blog.chorus.one on May 5, 2020.
Today, we are excited to announce that Chorus One will join the Band Protocol ecosystem as a block validator and data provider.
Band Protocol is a data layer for Web 3.0 applications providing decentralized off-chain data to smart contracts through community-curated oracles. Band Protocol is backed by a strong network of stakeholders including Sequoia Capital, one of the top venture capital firms in the world, and the leading cryptocurrency exchange, Binance.
Band Protocol 2.0 introduces BandChain, a blockchain built on the Cosmos SDK to accommodate user-defined data requests and support data oracles across multiple blockchains. Dapps can use BandChain to query data from traditional APIs and send it to the smart contracts in a verifiable and secure manner.
We have seen how price oracles have the potential to cause chaos in crypto. Synthetix had a close call when their price oracle failed last year. Recent flash loan arbitrage trades have shown that automated market makers like Uniswap can be fragile when low liquidity is paired with leverage. Similarly Terra, where Chorus One also runs a validator, saw their stablecoin swap mechanism subjected to arbitrage attacks leading to an effort to continuously improve the robustness of their oracle implementation.
We believe Band Protocol has the capacity to help mitigate oracle risks through their novel incentivized model on BandChain that incorporates flexibility, customizability, and speed while also ensuring the security and integrity of the data.
“As a validator and data provider on Band Protocol we hope to bring additional decentralization and security to all blockchain applications that seek to safeguard against critical failures arising from dependency on any sole oracle solution”
- Brian Fabian Crain, CEO & Co-Founder of Chorus One
Here are some of the reasons why we chose to support Band Protocol:
As Chorus One, we strongly believe in the Internet of Blockchains vision, as espoused by Cosmos and others. We believe that there will be many blockchain networks that all interact with each other and that, over time, these chains will become increasingly specialized. These chains will use inter-blockchain communication, via protocols like the Inter-blockchain Protocol (IBC), to securely transact with each other.
One key problem for the Internet of Blockchains is that blockchains are unable to verify data that is created outside of their network. This is known as the “oracle” problem and technologies designed to solve this problem are called oracles. Financial contracts need market data, insurance contracts need IoT data, and gaming applications need provable randomness. The oracle problem is such a fundamental one, we believe there will be many competing solutions, all providing unique benefits and making various data feeds available.
So while we recently partnered with Chainlink, the current market leaders in this space, we also see Band Protocol playing a key role in the evolution of oracles in the Internet of Blockchains. In an IBC context, oracles can bridge the Internet of Blockchains to real world data. As the Band Protocol network is built using the Cosmos SDK, it can operate as a Cosmos “zone”. This means it will naturally fit into the world of chains communicating over the IBC protocol, bringing high-quality data feeds to other application-specific chains built using the Cosmos SDK.
We expect to see many applications choosing to partner with multiple oracle solutions to improve resilience, as per the recent bZx announcement, where bZx have decided to partner with both Chainlink and Band Protocol to improve their price feed oracles.
We will be available to answer any questions you might have on the Chorus One Telegram group at https://t.me/chorusone, where we will host an AMA with the Band team on the 16th of April at 5PM CET.
About Chorus One
Chorus One is operating validation infrastructure and staking services for Proof-of-Stake networks.
We will offer staking on BandChain when the network goes live in April. You will be able to support our work and earn staking rewards by delegating BAND to our node.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
About Band Protocol
Band Protocol is a decentralized oracle framework for Web3.0 applications. Band Protocol connects smart contracts with trusted off-chain information, provided through community-curated oracle data providers. Blockchains are enabled to connect to any web API with assured data integrity through dPoS economic incentives through one simple function call. Developers using Band Protocol will be able to easily build and manage off-chain oracles, reputation scores, identity management systems and much more.
To learn more about Band Protocol, please check out their website here: https://bandprotocol.com/
Telegram: https://t.me/bandprotocol
Medium: https://medium.com/bandprotocol
Twitter: https://twitter.com/BandProtocol
Originally published at https://blog.chorus.one on April 2, 2020.
Background
Incentivised testnets have been one of the significant innovations in the crypto space. Cosmos led the way with Game of Stakes, and since then, it’s become a core activity for bootstrapping new networks.
Incentivized testnets are powerful in many ways. They enable validators to build up the skills they need to deploy, upgrade, and maintain the new network. But more than that, testnets help the validators learn how to operate as a community, where they work together to solve problems and make the network more robust. Often the incentives include rewards for maintaining high uptime or for passing a security audit. They may even include activities besides running validators e.g., rewards for content production. Incentivized testnets also give token holders a chance to evaluate the skills of each validator, to help them decide with whom to stake once the mainnet is launched.
A key part of running testnets is to break things. The premise is that the more successful attacks there are on a testnet, the more prepared a network is for mainnet. The best sign that a network has been put through its paces is to find the Holy Grail of bugs: a priority one, severe bug that is a showstopper for the network launch.
This week Chorus One engineer, Reisen, did just that. He demonstrated a critical flaw with the Solana network that allowed him to steal 500M Sol tokens on the testnet. What follows is the story of how he did it.
A Step Back
To start the story, we must go back to when Reisen joined the Chorus One team in June of 2019. Over the summer, Chorus was contracted by Solana to build out StrongGate, a solution that enables high-availability validators on the Solana network. This involved Reisen getting deep into some of the core Solana code. The Solana codebase would challenge any developer, even for a very experienced Rust and functional programming expert like Reisen. That is because the Solana project has innovated on so many fronts in parallel. Solana is built around eight vital technological innovations in one project (as described in this blog post). All these innovations were delivered in Version 1 of the Solana codebase, so when Reisen dove into the codebase, there was still a lot of development activity going on. And none of the eight technologies are easy to grasp. Proof of History is a new model for distributed timekeeping, Tower BFT is a new consensus algorithm, Turbine is a block propagation protocol influenced by BitTorrent, Archivers are a decentralized file system, and that’s only half of them. Anyone of these on its own would challenge any developer. So it was no easy task to dive into the codebase.
When Solana’s incentivized testnet (Tour de SOL) came around, Reisen was determined to come up with the best exploit. It was always in the back of his mind as we looked through the codebase in late 2019. But it wasn’t until Tour de SOL kicked off in February that he focused his attention on the problem.
The First Attacks
Designing distributed computing protocols in Byzantine environments is especially hard. The typical attacks we see on these networks involve crafting malformed packets or launching denial of service attacks. So this is where Reisen started.
His first attack was a joint effort with Certus One. Reisen had identified an issue at network launch time. Each node announces the height of the last block they have seen. The node with the most recent block is then responsible for sharing the latest block(s) to bootstrap the nodes that are joining the network. Reisen realized that this could be used to sabotage the network. By advertising a very high block height, he could control the launch. But the question was how best to exploit this? This is where the amazing Certus One team come in. They built a superb mechanism to slow down the snapshot delivery so that nodes would be effectively stalled trying to get access to the latest chain data before the network could start. They also prepared a compression (or zip) bomb that we deployed but unfortunately was never activated. And they designed the pièce de résistance, a beautiful piece of ASCII art to add to the mischief:
The attack worked! We had successfully attacked the network. Independently, Certus also launched other denial of service attacks on the network. It was such a pleasure for us the partner with Certus on this, as they have long been the rock stars of testnet attacks.
The fun had begun!
The Search For The Big Attack
So far, so good. But Reisen wanted more. He sensed there was a more significant attack possible. And then, last week, he spotted an issue in the code. At this point, it was just a suspicion that an attack might be possible. But he wasn’t sure.
So over a couple of sleepless nights, he set about setting up a test environment to build and test the exploit. Over the weekend, the Chorus team got early indications that the attack was viable. But could Reisen make it happen in the Tour de SOL testnet? We had to be patient as Reisen waited for the right opportunity.
This was the big one. It was the most critical exploit you can imagine in a crypto network: stealing unlimited funds. Reisen had found a bug that allowed a block producer to inject a transaction that could steal funds from any account without knowing the private key. And the network was utterly oblivious to anything being wrong.
But could we launch such a severe attack on Tour De SOL? Reisen felt that we should run it by one of the Solana team first. So we showed the exploit to Michael Vines, Head of Engineering at Solana. And it didn’t work at first. Reisen thought he’d messed up. Maybe there was something wrong with his test environment. He couldn’t reproduce it with Michael. But then, after seven attempts — it worked! We had reproduced it on the Solana Soft Launch testnet.
Now the big question. Could we make it work on Tour De SOL? Again the answer at first was no. It failed. Then it failed again. But at least Michael had seen the exploit working, so we still marked it down as a big success.
But as you may have guessed by now, this wasn’t good enough for Reisen. He needed to see this through. So he left the exploit on a loop. And an hour after we demonstrated the issue to Michael… The transaction went through. WE DID IT! We stole 500 Million SOL tokens from the genesis account on the Tour de SOL testnet.
Deep Dive Into the Issue
Let’s start with some terminology. Solana has slots, periods where a particular validator adds transactions. It’s helpful to think of a slot as a block in a more traditional blockchain context. Leaders are elected for a slot. They get to decide which transactions to include in that slot, during which time they broadcast these transactions to the other validators. Validators run in one of two modes: Broadcast and Replay. The leader broadcasts, while the other validators are in replay mode.
As is typical in blockchains, each transaction contains a set of public keys for the relevant accounts involved in the transaction. In the case of a simple token transfer, this is the sender and receiver public keys. For the token transfer transaction to be valid, it must be signed by the sender’s private key.
Simplified Transaction Format: [Signature, Sender Key, Receiver Key, Payload].
Check: Does Signature belong to Sender Key.
If you sign a transaction with a key that isn’t the correct one, then validators will fail the signature verification step. But this is not what happens when the leader injects a transaction.
The leader broadcasts the transactions they have included in the slot. Each validator receives those transactions, in what’s called replay mode. When transactions are replayed to a validator from the leader, the signature of each transaction should be verified. Instead the validator does a “light” check on the fields of the transaction. It looks to confirm that the correct keys are in place. There is a field in the transaction to indicate if the signatures have been previously checked (presumably by the node that accepted the transaction). But — and this is the critical flaw — the receiving validator does not actually re-run this validation of the signature i.e. there is no explicit check by the validator to verify that the owner of the account from which funds are being withdrawn has signed the transaction. In effect, the receiving validator trusts the transaction coming from the leader. This was the critical issue Reisen identified.
The steps he took were as follows:
But how come we had trouble reproducing the attack on the two testnets? The issue was that sometimes the malicious transaction the leader submitted never made it into the chain. The Solana network is so fast that it’s hard for a leader to inject transactions fast enough. But by retrying in a loop, the transaction was finally accepted into the chain. Reisen had succeeded through sheer grit and determination and found a way to steal 500M SOL on the Tour De SOL testnet.
The Solana Team Response
The Solana team’s response has been great.
The Solana codebase is excellent. The Rust compiler ensures type safety, which rules out whole classes of bugs. And the code is written defensively so that all inputs are checked. We just happened to find the one case where the robust checks we see everywhere else in the code were missed.
And now the hard work for Solana starts. Of course, questions must be asked on how this issue was missed in the recent security audit. But Anatoly (the Solana CEO) has given clear instructions to the team to review all the code, especially the crypto signing pieces.
We think this is the shock that every network needs as it prepares for the mainnet launch. We do not doubt that the Solana team will rise to the challenge to ensure that an issue like this never occurs again.
But at Chorus One we’re thrilled with our work! Reisen got his attack. And he got the much-deserved kudos from Anatoly (which is always lovely!):
And he got a new nickname: Reisen Hood, Prince of Crypto Thieves.
It’s been an amazing week for us. By a strange coincidence, Monday also saw some other big news for Chorus One. We launched Anthem, our multi-network staking platform, which allows token holders to track and manage Proof of Stake portfolios and earnings. Users can create a personalized staking dashboard for any Cosmos address, with detailed data and charts to cover your ATOM staking portfolio. Support for other networks is underway and will be coming soon. So please check it out at https://anthem.chorus.one.
