ickb / proposal

Proposal of iCKB: a NervosDAO liquid staking token
http://ickb.org
MIT License
8 stars 0 forks source link

Can two pairs of owned and owner cells be used interchangeably? #7

Closed XuJiandong closed 3 months ago

XuJiandong commented 3 months ago

Let's assume we have multiple owned owner cells during the minting stage:

Outputs:
    - Nervos DAO phase 1 withdrawal cell 1:
        Type: Nervos DAO
        Lock: Owned role
    - Owner cell 1:
        Type: Owner role
        Lock: A lock that identifies the user 1

    - Nervos DAO phase 1 withdrawal cell 2:
        Type: Nervos DAO
        Lock: Owned role
    - Owner cell 2:
        Type: Owner role
        Lock: A lock that identifies the user 2

The owner cell 1 and owner cell 2 share same relative index(-1). By intent, withdrawal cell 1 belongs to user 1, and withdrawal cell 2 belongs to user 2. However, during the melting stage, the following can be done:

Inputs:
    - Nervos DAO phase 1 withdrawal cell 1:
        Type: Nervos DAO
        Lock: Owned role
    - Owner cell 2:
        Type: Owner role
        Lock: A lock that identifies the user 2

    - Nervos DAO phase 1 withdrawal cell 2:
        Type: Nervos DAO
        Lock: Owned role
    - Owner cell 1:
        Type: Owner role
        Lock: A lock that identifies the user 1

Withdrawal cell 1 could be redirected to user 2, while withdrawal cell 2 could be redirected to user 1.

Since the entire transaction is assembled by the user, it may not be an issue, depending on the specific user scenario.

phroi commented 3 months ago

HeyΒ @XuJiandong, thank you for publicly expressing your interest in iCKB by reviewing the proposal and L1 scripts source code, I personally appreciate a lot!! πŸ™

This is an interesting hypothetical failure mode, pretty neat, keep this kind of issues coming!!

Withdrawal cell 1 could be redirected to user 2, while withdrawal cell 2 could be redirected to user 1.

Since the entire transaction is assembled by the user, it may not be an issue, depending on the specific user scenario.

Exactly, in a non-OTX setting this doesn't represent an issue as you noticed, once both users sign the tx, it's all good.

In a CoBuild OTX scenario, assuming:

Then it would be prevented by the CoBuild OTX validation.

phroi commented 3 months ago

To reply to the updated title:

Can two pair of owned owner cells interfere with each other validation?

Let's take the example you made and split it into two different txs consuming the created cells:

Tx A

Inputs:
    - Nervos DAO phase 1 withdrawal, owned cell 1:
        Type: Nervos DAO
        Lock: Owned role
    - Owner cell 2:
        Type: Owner role of owned cell 2
        Lock: A lock that identifies the user 2

Tx B

Inputs:
    - Nervos DAO phase 1 withdrawal, owned cell 2:
        Type: Nervos DAO
        Lock: Owned role
    - Owner cell 1:
        Type: Owner role of owned cell 1
        Lock: A lock that identifies the user 1

Would they validate separately?

Nope. Both Tx A and Tx B would fail validation as the owner metapoint and owned metapoint would differ.

In Tx A the loaded metapoints would be:

In Tx B the loaded metapoints would be:

So both txs would fail the Mismatch check.

Side Note about Limit Orders

Limit Order Mint and Melt work in the exact same way, except that it's the limit order cell that keeps track of the master cell.

phroi commented 3 months ago

@XuJiandong does all this sound reasonable?

XuJiandong commented 3 months ago

"Owner cell 1" and "Owner cell 2" are identical except for the lock field. I believe they can be used interchangeably.

phroi commented 3 months ago

I understand, it's not easy to see.

"Owner cell 1" and "Owner cell 2" are identical except for the lock field.

This statement is inaccurate and it's also the root of the current issue.

Given your Mint tx:

Outputs:
    - Nervos DAO phase 1 withdrawal cell 1:
        Type: Nervos DAO
        Lock: Owned role
    - Owner cell 1:
        Type: Owner role
        Lock: A lock that identifies the user 1

    - Nervos DAO phase 1 withdrawal cell 2:
        Type: Nervos DAO
        Lock: Owned role
    - Owner cell 2:
        Type: Owner role
        Lock: A lock that identifies the user 2

They also crucially differ for the outpoints:

I believe they can be used interchangeably.

Nope. The metapoints that I showed you before are calculated from the cells outpoints, that's why they cannot be used interchangeably.

Please, take some time to review owner metapoint and owned metapoint implementations.

At any rate, don't believe me, don't believe the code, try it out with a tx :hugs: (Let me know if I can help on this, ok?)

Side note: metapoint is nice code abstraction and it doesn't appear in the proposal. Metapoint is just an extension of outpoint, where the metapoint can also reference the current tx outputs, hence the use of Option:

XuJiandong commented 3 months ago

My conclusion: This approach works if they are in the same transaction but won't work across different transactions. Let's study my case provided before(in one transaction).

    - Nervos DAO phase 1 withdrawal cell 1:
        Type: Nervos DAO
        Lock: Owned role

This step applies the following setting: metapoint_2_accounting[tx_hash + 0].owned = 1

    - Owner cell 2:
        Type: Owner role
        Lock: A lock that identifies user 2

And this sets: metapoint_2_accounting[tx_hash + 2].owner = 1

    - Nervos DAO phase 1 withdrawal cell 2:
        Type: Nervos DAO
        Lock: Owned role

And this sets: metapoint_2_accounting[tx_hash + 2].owned = 1

    - Owner cell 1:
        Type: Owner role
        Lock: A lock that identifies user 1

Finally, this applies: metapoint_2_accounting[tx_hash + 0].owner = 1

It can pass the following validation:

    if metapoint_2_accounting
        .into_values()
        .any(|a| a.owned != 1 || a.owner != 1)
    {
        return Err(Error::Mismatch);
    }

It doesn't work if 4 cells are split into 2 tx.

phroi commented 3 months ago

Yup yup, that's 100% how this validation works, congrats @XuJiandong! πŸ₯³πŸŽ‰πŸŽ‰

While this concept is still hot, you may want to proceed to Limit Order Script.

If you have no more question about this, feel free to close the current issue.

phroi commented 3 months ago

Thank you again @XuJiandong for taking your time to understand and review the iCKB Scripts πŸ™