Simperby is an open-source blockchain engine developed by PDAO that allows OOs to create independent chains for their governance decisions. This is similar to how the Cosmos SDK enables the creation of Cosmos appchains.
Simperby is based on the principle of 3S: Standalone, Sovereign, and Self-hosted. This allows OOs to make their own decisions and governance the way they want, without relying on other chains or protocols.
Simperby is a governance tool that specializes in supporting multi-chain structures, which makes it a great fit for structures that OOs want to scale across multiple chains.
Thanks to @junha_yang for reviewing and providing feedback on this post.
Personally, I prefer to refer to organizations using blockchain technology collectively as Onchain Organizations (OOs). I think it's more constructive to call them all OOs, acknowledge the diversity within OOs, and view them from an inclusive perspective, rather than continuing to debate whether or not a particular DAO is actually a DAO. After all, the end goal is to make human collaboration easier through blockchain technology.
Organizations within OO take many different forms. They can be fully decentralized, which we call DAOs, or they can be BORGs, which use AI and smart contracts to reduce human error while still complying with current regulations, or they can be small groups of people who simply manage their collective funds as an onchain treasury. Each OO will naturally decide how much blockchain technology to leverage based on the purpose and context in which the organization was founded.
As shown in the table below, there are as many different OO tools as there are different forms of OO. The most common OO tools are OO frameworks that make it easy to create and operate OO, such as Snapshot + SAFE and Aragon.
Source: 1kxnetwork
1.2.1 Snapshot + SAFE
Snapshot is an off-chain governance platform that allows members of an OO to sign and vote on proposals through their wallets. Since most OOs using Snapshot manage funds on-chain, it is often used in conjunction with SAFE, a multisig treasury management solution. Since Snapshot is off-chain and SAFE is on-chain, the fact that the results from Snapshot are not directly executed in SAFE and require a middleman to intervene once again may be a concern for some OOs.
With this in mind, Snapshot has collaborated with UMA, the Optimistic Oracle protocol, to release a module called oSnap. oSnap allows anyone to submit a transaction that executes a result from Snapshot, and if no proof of fraud occurs during the challenge period, it will be applied to SAFE. Thus, oSnap reduces the reliance on multisig members, which is a drawback of the existing Snapshot + SAFE combination. In addition, Snapshot X, a voting framework built on top of StarkNet, a ZK-based Layer 2, allows OOs to have a similar level of security to on-chain voting at Layer 1 with minimal cost.
1.2.2 Aragon
Aragon is a project focused on making it easier to create and manage OOs through a more generalized framework. Aragon consists of two types of services: Aragon OSx and Aragon App.
First, Aragon OSx is a modular stack that allows you to create any conceivable form of OO using the smart contracts and governance plugins of the OSx protocol, with easy adaptation and replacement of governance plugins through the permission management system at the core of the OSx protocol. This allows OOs based on Aragon OSx to quickly and easily experiment with different governance. On the other hand, Aragon App is a user-friendly service that does not require any code writing and allows OOs to create OOs in a few minutes using the Aragon App's interface.
In addition to the two projects introduced above, existing OO tools such as DAOHaus, Colony, and Syndicate have focused on improving the UX of creating and operating OOs, and on supporting various forms of OOs. These projects do this by providing easy-to-use interfaces, minimalist, generalized OO frameworks, and plugins and extensions that allow OOs to customize them to their liking.
The reason why Simperby is interesting is that it has a different methodology, goals, and targets than the existing OO frameworks. Therefore, although it is difficult to say that Simperby is superior to the existing OO frameworks, it will definitely be more attractive to some OOs than the other existing OO frameworks.
Simperby is a blockchain engine for OO developed by the open source foundation PDAO. By analogy, just as the Cosmos SDK allows you to create a Cosmos app chain, Simperby allows each OO to have its own chain for governance. The chain created through Simperby is only a chain for OO decision-making and consensus, and does not support smart contracts, and since it is only for authorized OOs, there is no token or gas fee.
2.1.1 Target
Simperby is best suited for OOs with the following characteristics or needs:
Simperby targets permissioned OOs that require the consent of existing members to add new members. Therefore, OOs that only need a token to freely participate in governance are not a good fit for Simperby. In general, real-world organizations are mostly permissioned OOs, and on-chain native OOs are mostly permissionless OOs, but this is not always the case. In the case of the FWB DAO, it can be said that it has some characteristics of a permissioned OO, as it requires the consent of committee members to participate, rather than simply owning $FWB tokens.
In addition, Simperby is best suited for OOs that prioritize 3S values. **3S stands for Standalone, Sovereign, and Self-hosted. Simperby allows OOs to have their own chain for communication and governance, allowing them to make decisions and governance as they wish, without dependency on other chains or protocols.
In the case of Standalone and Sovereign, it can be easily assumed that this is achieved by each OO having its own chain. However, there is one aspect of the 3S that may be questionable: Self-hosted. In general, it is not only difficult for an individual to run a node on a blockchain, but it is also very inefficient in terms of cost and resources, so it is almost impossible to ask ordinary people to run nodes.
For this reason, the Simperby team has added a number of technical mechanisms to make it as easy and simple as possible for the public to operate nodes in the chain created by Simperby. As you'll see later, OO members can easily run a node from their laptops, only need to be online occasionally if they're not the leader of a round, and can easily predict when they'll need to be online in advance. By reducing the burden of running a node, we've made it possible to be both Standalone, Sovereign, and Self-hosted.
2.1.2 Glossary
Before we discuss Simperby further, let's clear up a few terms that may be confusing.
Simperby chain: A chain created through Simperby, where each OO has its own Simperby chain.
Agenda: The governance proposal, the members of an OO vote on the agenda.
Member: A participant in the governance process.
Validators: Participants in the consensus process. Validators are a subset of members.
Settlement chain: Another chain that an OO using a Simperby chain interacts with, for example, if an OO has a treasury on Ethereum, Ethereum is its settlement chain.
Simperby chains allow OO members to communicate, vote on agendas, and reach consensus on those results.
2.2.1 Chat
Simperby chain provides a communication channel for nodes to communicate with each other like a discord through a P2P network. Anyone can send a message by signing it with their public key, and each message contains the hash value of the previous message to form a chain, which we call a chat chain.
For chat chains, the canonical chain is determined by the longest chain rule, and the block proposer in each round is responsible for semi-finalizing the chat chain. Block proposers will periodically submit an checkpoint called "ack" chat to the longest chain in their view, and other members will continue chatting on that chain.
2.2.2 Governance
Governance is actually the process by which the members of an OO pass an agenda together. Anyone can propose an agenda, which is then propagated through the peer-to-peer network of chats we saw earlier. If members agree with the agenda, they vote with their signatures. Agendas that are agreed to by more than 50% of all members are eligible for inclusion in the block, which we call eligible agendas.
2.2.3 Consensus
Consensus is the process by which the state of the OO is determined in a decentralized network by including a particular agenda in a block and confirming that block. A block proposer must immediately propose a block containing a eligible agenda as soon as it appears. If there are multiple eligible agendas, the block proposer chooses one of them to include in the block. In general, you'll want to include the first one that becomes eligible. Because of the problems that arise when agendas are correlated, only one agenda can be included in a block.
Aside from the agenda, the block proposer can include some information in the block that does not require a governance vote.
Block proposer can semifinalize the chat chain at the moment a particular agenda becomes a eligible agenda and include it in the block.
Accuse a block proposer from a previous round of malicious behavior, leading to the slashing of their validator.
Delegate and re-delegate voting rights to specific members. This requires the signature of the member.
2.2.4 User Flow
Taken together, user flow of using Simperby for governance is as follows:
Someone in the OO proposes a new agenda.
Members chat and vote on the new agenda over a peer-to-peer network.
If the agenda is accepted by enough members, it becomes a eligible agenda, and the block proposer for that round semi-finalizes the chat chain to create a checkpoint.
The block proposer proposes a new block containing the eligible agenda.
The validators in OO go through a consensus process to reach a consensus on the block.
The new block is executed differently depending on the type of agenda it contains. Agendas can range from modifying the governance parameters of the OO, to accusing a member of malicious behavior, to using another chain's treasury, etc.
As mentioned earlier, for Simperby to realize the value of being self-hosted, each individual in the OO must be able to run a node, and for that to happen, running a node must be simple and not resource intensive.
3.1.1 Online only when needed
Validators in the Simperby chain do not need to be online all the time, but only when they are needed, such as to chat, vote on agendas, or participate in the consensus process. In a normal blockchain, it is necessary to have 24/7 uptime because blocks need to be generated continuously without stopping, but in Simperby chain, since it only processes governance agendas by the permissioned set, it is not necessary to generate blocks all the time, but only on-demand, so there is no problem. **However, this requires that the timeout for each round is long enough (e.g., 2 weeks) to allow all nodes to appear before the timeout.
3.1.2 Who will propose blocks?
Unlike regular validators, block proposers need to have relatively higher uptime because they need to constantly monitor and semifinalize the chat chain and propose blocks that contain eligible agendas when they are created. To predictably place this burden on a small number of validators rather than all validators, Simperby uses a leader-based and stable leader approach.
Leader-based: Unlike Leaderless, not everyone can propose a block, and it is deterministic who will propose a block and when, like a round robin. The advantage of this method is that it is an efficient method that reduces communication costs, but the disadvantage is that performance can drop significantly in the event of a DOS attack or if the block proposer is malicious.
Stable-leader: The existing block proposer continues to lead unless the block proposer is explicitly replaced. This approach gives a few members a little more responsibility and authority, reflecting the fact that not all members may be suitable to be block proposers in the real world. The stable leader approach also makes it easier for each validator to predict when they will assume the role of block proposer based on the stable leader list.
3.1.3 Side Effects
Because Simperby uses leader-based and stable-leader methods, it requires a mechanism to replace the current block proposer when he/she has not fulfilled his/her responsibilities and authority in good faith. In fact, in normal Tendermint, you can just wait for the round to end, but in Simperby, the round time is extremely long, so waiting for the round to end is too unusable.
There are also many cases where pogrammable slashing is not possible due to malicious behavior by the block proposer . For example, deliberately not including certain eligible agendas in a block, or not creating a block as part of a eligible agenda, are both malicious behaviors that cannot be recognized at the line of code.
To solve this problem, the Simperby team came up with Vetomint, a unique consensus mechanism that is a variation of Tendermint. The essence of Vetomint is that validators in the Simperby chain can vote to veto or replace the current block proposer during the consensus process if it is not acting in good faith..
As mentioned earlier, Vetomint is an adaptation of the existing Tendermint for the specialized environment of Simperby. The main differences between Vetomint and Tendermint are as follows.
3.2.1 Nil Prevotes can be exercised before the end of the round.
In Tendermint, validators cast a nil prevote if a block proposer fails to propose a block in time. In contrast, Vetomint allows validators to cast a nil prevote before the round's timeout expires. Validators can cast a nil prevote if they believe the current leader is not behaving properly, regardless of whether the block proposer has actually proposed a block. Like Tendermint, Vetomint will move to the next round with a new leader if the number of nil prevotes exceeds 2/3 of the total validator set.
3.2.2 Early Termination
In Tendermint, if the number of non-nil prevotes exceeds 2/3 of the total set of validators, the project moves to the precommit phase. **In contrast, Vetomint will proceed to the precommit phase based on these tables if prevotes exceed 5/6 of the total validator set, regardless of whether the validator is nil or non-nil.
The reason for this design is that in Simperby, the timeout for each round is very long, and validators can subjectively cast nil prevotes. For example, if half of all validators cast non-nil prevotes and the rest cast nil prevotes, then using Tendermint as it is, we would not be able to move to precommit and would have to wait for a long timeout because we do not have more than 2/3 non-nil prevotes. So, in Vetomint, if a validator has more than 5/6 of the total prevotes, we check to see if non-nil prevotes exceed 2/3 of the total prevotes at that point, and only then propagate a non-nil precommit.
Tendermint does not have the same problem as Vetomint because the timeout for a round is short, and honest (non-byzantine) nodes cannot differ in whether they are non-nil prevotes or nil prevotes.
3.2.3 So why 5/6?
We call 5/6 the threshold for triggering early termination, or the early termination threshold. Why did we set the early termination threshold to 5/6?
Let's start with why not 2/3. If the early termination threshold was 2/3, then under normal circumstances, if even one Byzantine node deliberately cast a non-nil prevote, the validators who received it would not be able to move on to the next step.
If the early termination threshold is x, and the value of the byzantine threshold is greater than 1-x, then Byzantine nodes can prevent progression to the next phase even if they do not prevote. For this reason, the byzantine threshold must be less than or equal to '1-x'. Our goal is to proceed to the precommit phase when there are more than 2/3 non-nil prevotes, without being affected by the behavior of Byzantine nodes. Therefore, x must satisfy the following equation.
x - (1-x) ≥ 2/3, x ≥ 5/6
Among the x prevotes, the votes of Byzantine nodes must be less than 1-x, and the votes of honest nodes must be at least 2/3 of the total. Therefore, the minimum possible value of x is 5/6. This means that Vetomint is guaranteed to be safe when there are less than 1/3 Byzantine nodes and lively when there are less than 1/6 Byzantine nodes, just like Tendermint.
Simperby's Standalone, Sovereign, and Self-hosted features make Simperby a very attractive governance tool for OOs looking to scale to multiple chains.
In the future, most OOs are expected to be multi-chain OOs. For one thing, it's much safer to hold funds in treasuries on multiple chains than it is to be locked into a single chain from a risk diversification perspective. For OOs that govern dApps, it is inevitable that they will have a multi-chain OO in order to apply governance decisions to multiple chains at once as they scale their dApps to new chains. The most prominent example of this is Uniswap V3. Uniswap's new expansion to the BNB chain required them to select a third-party bridge to transfer governance decisions from the Uniswap DAO on the Ethereum chain to the BNB chain, and after a lengthy process, Wormhole was selected.
Simperby is a lightweight client that allows multi-chain OOs to pass messages to the settlement chain in a trust-minimized manner. Simperby's light clients in the settlement chain only update when a new header is actually finalized in the Simperby chain, which is verified by ensuring that the header has a pre-commit of more than 2/3 of the total validator set. The merkle root in this header, along with the merkle proof received from the full node, allows light clients to verify that a particular transaction was actually included in the block.
For example, let's say a block contains an agenda from a certain OO's Simperby chain to withdraw 3 ETH from a treasury on that OO's Ethereum chain. In this case, a light client that exists in the form of a smart contract on the Ethereum chain can verify the signatures of the validators on the Simperby chain and execute the required transaction in a trust-minimized manner.
Source: Simperby Deck
Since the Simperby chain only makes decisions related to governance, and the members of the OO only need to verify that what is directed by the Settlement chain has happened, the connection between the chains is only one-way, from the Simperby chain to the Settlement chain. Thus, OOs using Simperby have extreme freedom to join and leave a particular chain whenever they want.
While Simperby is a blockchain for governance, it can also function as a distributed file storage like Google Drive. All finalized data in Simperby (agendas, chats, blocks) are stored in the 'finalized' branch of the Git repository. Each node in the Simperby chain maintains its own git repository and can read, validate, or synchronize data from other nodes via git fetch.
Simperby and Git have an interesting one-to-one correspondence. For example, agendas are correlated to 'git commit', block proposals to 'git branch', block confirmations to 'git rebase', and so on. This fact makes Simperby more than just a governance tool, it is a distributed file repository for OO, and it synergizes well with existing third-party tools in the Git ecosystem.
As you can see, Simperby is definitely different from other OO frameworks. The fact that it creates a chain for governance and its own consensus mechanism for OO members to run their own nodes is pretty cool, but the fact that Simperby can be used not just for governance, but also as a distributed data store via Git is very interesting. PDAO, the open source foundation that developed Simperby, is already running on SImperby, and many organizations, large and small, will be using it to make decisions in the future.
For those who are used to traditional on-chain governance, Simperby may be a bit awkward at first, but for real-world organizations and groups that are new to blockchain, I think Simperby may be the most attractive OO framework because they don't have to worry about gas costs and don't have to know how to use existing blockchains like Ethereum.
Thanks to Kate for designing the graphics for this article.
FLock.io
Cosmos
LayerZero
