Trust Model
A key requirement in Spark is that a threshold of Spark Operators must all cooperate to authorize a transaction. The protocol is designed such that a Wallet can always be sure that this threshold was involved in authorizing and completing the transaction and never has to trust a single Spark Operator to behave honestly.
Distributed Revocation Keys
We utilize a cryptographic process called Distributed Key Generation (DKG) enabling the distribution of a shared set of keys. SOs for each transaction go through a process to generate a shared secret which maps to a Revocation Public Key such that a threshold of these keyshares need to be combined in order to derive the underlying Revocation Key.
Spark uses revocation keys to be able to verifiably invalidate older versions of a transaction and prevent double spending. When a wallet constructs a transaction, it sets a mutually agreed upon revocation commitment with the Statechain operators.
By utilizing DKG, a wallet and SOs can agree upon a revocation key without any individual having full access to the key until a threshold of SOs cooperate.
When StartTokenTransaction() is requested by a wallet, a single SO chooses an unused previously generated DKG key and tells all of the other SOs to also reserve that key for use in the generated LTTXO. It then returns that reserved public key to the Wallet.
When the Wallet then calls Sign() with each SO operator, each SO operator has the opportunity to validate that the Revocation Public Key associated with each output indeed matches the value that was reserved earlier, thus validating that the Revocation Key output was not unilaterally chosen by a single SO and that the only way the Revocation key can be derived is by collecting a threshold # of keyshares from the SO set.
The Wallet is then able to verify with each SO individually that the Revocation Public Key associated with a transaction output indeed matches a Revocation Keyshare that only the Wallet can derive if a threshold of SO’s releases their keyshares. Honest SO’s will only release this keyshare if the Wallet can prove (via signature) that it is able to spend that output.
Spark Operator Signature Redundancy
When executing token transactions on Spark, the Spark Operators represent a collective ‘witness’ for the execution of a transaction. We have extended the LRC20 Node implementation to require for a given Spark transaction that a full threshold of SOs specified by a Wallet sending funds has signed the Final Token Transaction and provided it to the LRC20 Gossip Network.
This is accomplished with two mechanisms.
First, when constructing a PartialTokenTransaction the Wallet specifies the list of known Spark Operators that it expects to be involved in the authorization of the token transaction. This locks in the expected SOs that make up the Spark Entity.
Second, when signing, the Wallet communicates with each SO individually to acquire its respective signature authorizing the transaction and making it irreversible in its eyes. This allows the Wallet to know that a threshold of these SO’s have actually signed off on the transaction as it expects. Equipped with these signatures, the Wallet is then able to prove to the wider LRC20 gossip network that it has a threshold of SO witnesses which have authorized the transfer and/or issuance of tokens.
By having the SO set pre-determined by the wallet and hardcoded in the actual Wallet signed transaction, and also having the Wallet retrieve each SO signature individually, the Wallet, the SO set, and the LRC20 Gossip Network now all have the necessary signatures to show that the a full threshold of SOs have been involved in and have signed off on the movement of funds.
Withdrawal Bond
A unilateral exit transaction requires that the Wallet posts a bond in Sats which can be recovered as soon as the locktime waiting period is fulfilled. This provides economic disincentive preventing a malicious entity from broadcasting a large number of Spark Transactions to chain in an attack on the protocol.
The downside of this requirement is that wallets holding large numbers of leaves could be at risk of having a potentially high up front cost to unilaterally exit to L1. This risk can be mitigated by Wallets proactively using a consolidation self-transfer to keep their owned LTTXO set small.
Watchtower Redundancy
Watchtowers are vital to prevent cheating through an attempt to broadcast revoked TTXOs to L1. For that reason, it is critical for there to be redundant watchtowers. For this reason, each SO in the SE will run its own watchtower. Only one honest SO then is needed to prevent the broadcast of revoked Outputs.
Also, it’s worth noting that Operators are incentivized to run Watchtowers not just to help maintain the trustlessness of the network but also because they will be able to claim the Bond of the cheater if they are the fastest to use their revocation key to sweep the funds to their wallet.
Finally, if a Token Holder seeks an additional layer of security they could alternatively run their own Watchtower by subscribing to updates from LRC20 nodes, although for most users this should be unnecessary.