This is a joint post from Nomadic Labs, Trilitech, and Functori.
We are happy to introduce the next upgrade proposal for the Tezos protocol. Destination: Seoul!
As usual, the “true” name of the proposal is its hash:
PtSeouLouXkxhg39oWzjxDWaCydNfR3RxCUrNe4Q9Ro8BTehcbh
The command to inject or upvote the proposal via the Octez client is:
octez-client submit proposals for <baking_key> PtSeouLouXkxhg39oWzjxDWaCydNfR3RxCUrNe4Q9Ro8BTehcbh
The Seoul protocol proposal seeks to improve the staking user experience, enable collective or institutional staking and baking, as well as general network performance improvements. The main changes are:
- Native multisig accounts: Network support for native multisig accounts strengthens security for institutions and other multi-user setups, which can boost staking.
- Aggregated attestations: Aggregating attestations into a single operation in each block unlocks improved network performance and security.
- Open unstake finalization: The protocol is adjusted to make unstake operations finalizable by any user, enabling off-chain solutions that automatically finalize unstaking for all users.
Below we expand on the changes. For more details and additional minor changes, see the Seoul proposal’s changelog.
Native multisig accounts
The Seoul proposal introduces support for protocol native multisig (multi-signature) accounts – a feature that has been requested on several occasions by ecosystem members.
Having a single private key for an account is simple and effective for most users, but can present challenges for more advanced users:
- The security of the account relies on a single secret key. If this key is compromised, an attacker can gain full control of the account.
- The single-key model is not well-suited for organizations or shared accounts, where multiple users manage the account collectively.
To offer better UX for institutional users and other collectively managed setups, the Seoul protocol introduces a multi-signature solution using the BLS signatures behind tz4 accounts.
This solution does not change the protocol itself, but offers RPCs and client commands to facilitate the signing of operations within a multi-user setup. From a protocol perspective, single-user and multi-user tz4 accounts are the same.
To learn more about how multisig accounts work, see the documentation and our Tezos Agora post.
Aggregated attestations
The Seoul protocol proposal enables attestations in a block to be aggregated into a single operation, instead of having one operation per attesting baker.
This unlocks significant efficiency gains on Layer 1 and paves the way for further block time reductions. Most notably, bandwidth and storage needs for bakers are reduced dramatically —- up to 63x less, or from 900 MB/day to 14 MB/day.
Aggregated attestations rely on BLS signatures, and bakers will need to bake from a tz4 account to participate in aggregating attestations. However, it will still be possible to bake with non-tz4 accounts in the Seoul protocol. Blocks will carry both individual attestations from bakers using tz1, tz2, or tz3 accounts, and a single aggregated attestation from those using tz4.
As tz4 adoption grows, it will eventually be possible to have only a single aggregated attestation in each block, unlocking greater network performance.
Another benefit of full tz4 adoption is that it enables each block to be attested by all bakers. Currently, only a subset of bakers (\~200 out of \~300) attest to each block due to bandwidth and disk footprint considerations. Having all bakers attest each block has several benefits:
- More attestations per block make L1 more secure.
- Rewards calculation is simplified, as attestations exactly match staking power.
- The need to calculate attesting rights at each block is removed, boosting network performance.
A note on signer setups: Our tests show that current Ledger hardware devices will not work for baking with tz4 accounts. The BLS12-381 curve used for signing is more computationally demanding and makes signing on these devices prohibitively slow.
Also, some popular cloud KSM solutions currently don’t support BLS signatures.
Alternative and promising solutions are already being tested, and we will present more information soon. Bakers will have ample time to adapt their setups.
For more information on aggregated attestations and baking with tz4 accounts, see our Tezos Agora post (and discussion), and the Octez documentation.
Open unstake finalization
After submitting a request to unstake tez, users must currently wait up to 4 cycles (4 days) to be able to manually finalize the unstake and make funds available. A common community request is to automate this step.
We are currently exploring how to automate this at the protocol level in a way that aligns with other important objectives, namely minimizing layer 1 block time for lower latency and faster finality.
To improve the staking user experience in the near term, the Seoul proposal includes a small change to the protocol: allowing any unstake operation to be finalized by any user.
This way, an off-chain bot can be set up to scan the network for finalizable unstake operations and finalize them automatically, so users don’t need to finalize unstake operations themselves. This would also simplify user flows for Tezos wallets and other applications like the Tezos staking dapp or Stacy.fi.
To be clear, this change applies only to finalizing unstake operations and does not entail any transfer of ownership (or funds). Initiating an unstake operation can only be done by the account owner. Also, finalizing an unstake operation has no influence on ownership. Upon finalization, the unfrozen funds always accrue on the account owner’s spendable balance.
We are preparing an implementation of a finalizer bot, and we’ll present more details about its deployment in a future update. Note that while anyone might indeed be able to run their own instance of a finalizer bot, there are no incentives to do so beyond providing redundancy. Moreover, the operators of the finalization bot have to pay the gas fees associated with the “finalize unstake” operations.
Preparing for Seoul
While the Seoul proposal undergoes the governance process, we invite bakers and other stakeholders to join the upcoming ‘seoulnet’ test network.
A release candidate for Octez v23, which contains the Seoul protocol, as well as general improvements, will also be announced in the coming days.
As always, we can be reached in Tezos Discord #baking channel for further questions and feedback.
Let’s go to Seoul!