Adamantium - Power Users

TL;DR: we propose Adamantium, a protocol for Autonomous Data Availability, which retains the scaling benefits of off-chain data availability, while removing all trust assumptions for any willing user. Willing to do what? To be online; and if they aren’t online, their funds cannot be stolen, nor frozen - rather, the funds are moved from L2 back to an Ethereum address under the user’s control.

Background
Validium relies on a DA Committee (DAC), made up of a set of reputable players in the blockchain space. DAC members store off-chain a copy of the account balances, and attest to the availability of its state S by signing the Merkle root of S after every batch processed by the StarkEx Operators.
Validium’s trust assumptions: Validium requires users to trust DAC members in one very particular scenario, which we call the Escape Hatch. In case the StarkEx Operators censor a user’s withdrawal request, users trust at least one DAC member to publish a current copy of the latest state S (read a complete description of the protocol here). Can Validium be improved and made completely trustless? It can, and we call the improved protocol Adamantium.

Description
In Adamantium, users can operate in a fully trustless manner, by choosing to become a Power User (PU). The funds of a PU are always in her custody: typically a PU provides a signature that she has access to her own off-chain data, thus allowing her to activate her personal Escape Hatch with the Application Smart Contract on L1. Absent that timely signature, the PU’s funds are automatically withdrawn back on-chain (aka Protective Withdrawal).
What about users who do not wish to become a PU? With Adamantium, they have a wider set of choices. They will no longer be restricted to trusting a DAC member - they can opt to trust any Power User willing to serve as a watchtower on their behalf (and would have to authorize that PU to do so).

Participants:

  • DAC: The DAC continues to operate, and offer its services to any interested users (i.e. app users)
  • Users:
    • Regular Users: Users can continue to operate as they did previously, and rely on the DAC to fill its role, as described above.
    • Power User (PU): A user who trusts no one - not the DAC nor anyone else.
System Design Implications & Economics:
  • PU (Power User):

    • A PU has one or more Merkle tree vaults mapped to it - these are the vaults she signs for
    • A PU is generally expected to be online:
      • Response time: a PU needs to provide her signature within a proof-generation time frame, so her response time is measured in minutes, not seconds.
      • Cost: they have enough at stake, and care enough not to trust other parties, to warrant the hassle and expense.
        • When on-line: PU performs the same computational work as a DAC member: they need to hold the balance tree and verify the Merkle tree up to the root.
          We estimate the PU’s monthly computational cost to be a few $100s/month.
        • When going off-line: a Protective Withdrawal is executed.
          Protective Withdrawal - the protocol-enforced withdrawal of funds back on-chain as call data - is the key innovation in Adamantium. Absent a timely cryptographic signature from the PU, the Operator is forced to make the funds available to the PU on mainnet.
          In a given proof batch cycle, the Operator pays for call data only for those users who went off-line during that cycle. Importantly, this gas expense does not scale with the number of transactions in a given batch, nor with all users who are merely still off-line. Naturally, the Operator may charge the PU for this sequence.
  • Application Operator (e.g. the exchange):

    • Adamantium Vaults: The Application Smart Contract tracks the vaults mapped to every PU.
    • Protective Withdrawals Cost: Tx batching reduces the gas cost of a Protective Withdrawal so the amortized cost approaches the gas cost of placing the data on-chain.
    • An Operator can ignore a PU’s signature, thus triggering an unwarranted Protective Withdrawal. Repeating this kind of ordeal too many times will simply cause PUs to switch to a competing application.

* Other than running an Ethereum node
** Till you withdraw

Protocol Extension: Followers of a PU

A Follower is a user who chooses to put their trust in one or more PUs that provide them with a watchtower service for a fee. A PU should sign not only for their own vaults, but also for the vaults of their Followers.

A Follower’s funds will be withdrawn back on-chain only if none of the PUs it follows have provided their timely cryptographic signature. By following multiple PUs, a Follower reduces the likelihood that a chance disruption of service by any single PU will result in a withdrawal of funds.

A PU could ignore a Follower’s signature, thus triggering an unnecessary Protective Withdrawal. We believe this kind of behavior will be very limited in scope, as Followers will simply switch to more reliable PUs.

6 Likes

Nice idea, but I still don’t get how is the operator forced to withdraw PU’s funds onchain. Could you please elaborate more?

Even if the withdrawal is enforced on the smart contract during each proof execution, why can’t the operator stop producing blocks?
Also, why can’t the operator ignore adding new PU’s, or the addition of a new power user should be done on-chain?

For a state transition to happen, a proof attesting to the validity of this state transition has to verified on-chain.
Part of the statement being proven says that, for every PU, either they signed, or their funds has to be withdrawn. So if the operator wants to post a new state transition, they have to withdraw that PU funds.

The operator can stop producing blocks. In this case, every user can submit an on-chain request to withdraw their funds. If the request isn’t fulfilled by the operator after some time, users can freeze the system and withdraw funds from the merkle root by presenting the merkle path to their balances.

If the operator ignores adding a PU, this user can choose not to deposit funds to the system while their request is not approved.

2 Likes

Interesting idea. How about assets that are defined only in Validium? Will the system redeem or exchange these assets into L1 assets so that users’ funds can be entirely withdrawn. For example, if power users have liquidity tokens of an AMM SC in Validium, the withdrawal of funds to L1 might require the burn of these tokens to redeem the initial L1-compatible token pair.

A withdrawal process should be defined also for this type of token.
In StarkEx, for example, tokens that are minted on L2 can be withdrawn to L1 and will be minted there. So yes, in similar lines to what you described.

I think there is a nice tradeoff that enables PU to only do log(n) work instead of O(n), in return for publishing log(n) data per withdrawal.

In the original proposal, PUs are holding the state so they can update their witnesses based on withdrawal data.
Well, what if withdrawal data will include not only the withdrawal but also the list of nodes changed because of it?
Then it’s enough for PU to only hold their witnesses and it would be possible to update them based on this data.

We are getting the worst case to be x log(n) data on-chain for PU to do log(n) work and not O(n).

1 Like

In fact, we have a similar idea but instead of having Validium as default, we have Zk-rollup as default setting. If a Tx is included without any confirmation, its data must be published just like Zkrollup. Each time users confirm that they have data availability, the blocks that include their Txs can omit some on-chain data. The factor of gas economic maybe lower than Adamantium but it is more convenient for small users.