Recently, $Obol was listed on Binance, and we take this opportunity to discuss Obol's technical architecture.
First of all, the significance of the Obol project is to help increase fault tolerance in ETH Staking.
To put it imprecisely, Obol essentially creates a multi-signature mechanism specifically for managing Staking.
The most common scenario is: if you run an Ethereum client to Stake ETH directly, once your node goes offline, not only do you lose the time while offline, but you may also incur penalties in the form of ETH being deducted.
Therefore, preventing ETH Staking nodes from going offline has become a research topic for everyone.
Obol's solution is:
While running the ETH client, you run an additional Obol client (middleware).
After running the Obol client, you can choose 3-10 node operators to jointly manage your node, so even if several nodes go offline, the other nodes can continue to operate normally.
PS: Of course, theoretically, you can also run multiple servers yourself or have your friends help you run them.
However, while this process seems easy, it has its challenges in implementation.
The ETH Staking mechanism is already established, and there was no designated space for the DVT protocol in its initial design, which means that DVT protocols must operate under the constraints of the existing ETH Staking mechanism.
Thus, the circumvention method employed by Obol is to run additional clients through the nodes, establishing an Obol network that operates independently of the ETH network.
(Charon is the name of the Obol client)
This network is a peer-to-peer network that solves the communication security issue between different nodes.
Then, after the nodes in the same group complete mutual handshaking, they will hold a DKG ceremony.
The so-called DKG stands for Distributed Key Generation, and this design can achieve (taking 3/4 signatures as an example):
1. No intermediaries
2. Four nodes are unaware of each other's key fragments
3. At least three nodes online can perform validator work
In this way, the private key is stored locally on the nodes. Additionally, Obol does not perform the action of [splitting]; it directly requires nodes to generate one of the fragments locally, thus avoiding the issue of keys being exposed on the network.
Furthermore, since ETH Staking itself consists of [asset private keys] and [validator private keys],
similar to non-custodial Staking, the DVT protocol here is also only responsible for the validator key and does not touch the asset private key, which is always held by the ETH holder.
Thus, even if there is collusion among multiple parties in the DVT protocol, the most they can do is interfere with the nodes' ability to produce blocks, but technically, they cannot steal your Staked ETH directly, resulting in actual principal loss.
On the contrary, if your Staking accidentally goes offline, the other 3 can still rescue your node.
There are also some interesting small mechanism designs, such as Obol allowing those clients to decide on upgrades based on their own will, enabling different versions to run without requiring simultaneous upgrades.
Therefore, when Obol releases a new version, the existing 3/4 that do not upgrade can still continue to use it, as long as the clients within the group remain consistent. This minimizes the possibility of faults caused by the Obol official.
This is how Obol increases the fault tolerance of ETH Staking through its technical principles.
