In SUI whitepaper it is mentioned that:
Sign once, and safety. All owned input objects locks in Lockš£ [Ā·] are set to the first transaction Tx that passes the checks using them, and then the first certificate that uses the object as an input. We call this locking the object to this transaction, and there is no unlocking within an epoch. As a result an authority only signs a single transaction per lock, which is an essential component of consistent broadcast [6], and thus the safety of Sui.
What does this mean? Specifically, this part where it says there is no unlocking within an epoch. What does an epoch mean in this case.
Is it like Suppose?
Initial state: I have an NFT object (letās call it NFT1) that I own. The NFT1 object is not locked to any transaction.
Transaction TX1: I create a transaction TX1 that transfers NFT1 to user B. When I submit TX1 to the Sui authorities, they perform the necessary checks. If TX1 passes all the checks, the authorities lock NFT1 to TX1 in their order lock map (Lockš£[NFT1] ā TX1).
The authorities sign TX1, creating partial certificates (TxSign).
Certificate formation: The partial certificates (TxSign) for TX1 are collected and combined to form a complete certificate TxCert(TX1).
Once TxCert(TX1) is formed, the authorities update their lock map to point NFT1 to the certificate (Lockš£[NFT1] ā TxCert(TX1)).
Attempt to create TX2: Now, letās say user B tries to create a new transaction TX2 that transfers NFT1 to user C within the same epoch. When B submits TX2 to the Sui authorities, they perform the necessary checks. The authorities check their order lock map (Lockš£) and find that NFT1 is already locked to a certificate TxCert(TX1). Since NFT1 is locked and cannot be used as an input in another transaction within the same epoch, the authorities will reject TX2.
However in reality this isnāt the case right? Like what am i missing or can anyone please help me to understand this.
Hi @bipin_bhandari, the key thing to understand is that a lock is associated with a particular version of an object, and modification is modeled by consuming the old version and creating a new version (which has a new lock), so your example is accurate, and the only thing I would modify is that wherever you see NFT1 replace it with NFT1(v) (meaning version v of NFT1):
Initially, you have a version of NFT1, NFT1(v), that you own, and that has not been locked to any transaction.
You create a transaction TX1, that accepts NFT1(v) as input (note that you need to specify the version of owned objects you are using).
You send this transaction to Sui authorities, it passes transaction verifier checks, each authority locks NFT1(v) for use with TX1, and you get back a partial transaction certificate from each of them.
You gather a quorum of partial signatures, enough to form a complete certificate, and you send this to the the authorities to execute.
Once they execute, assume TX1 creates a new version of the NFT: NFT1(w) where v < w.
If you attempt to use NFT1(v) in a TX2, you will not be able to get a quorum of signatures for it, because over 2/3rds of validators have already committed NFT1(v) to TX1, but they will happily sign a transaction that tries to make use of NFT1(w), which has not been locked for anything yet.
The detail about epochs is that if a lock is held during an epoch and the transaction has not been executed, the lock will be dropped. This is to deal with equivocation:
If you created two transactions, TX1 and TX2 that both used NFT1(v) and sent them each to F + 1 (non-overlapping) authorities, each group of F + 1 would sign, but neither would be able to get a quorum, so their inputs are stuck in limbo ā they are locked but the transaction they are locked for will never run. Dropping unused locks at the end of the epoch offers a way out in this case (you can wait until the end of the epoch and then try again).