Manager

The PlasmaRifle Root-chain Manager

The PlasmaRifle Root-chain Manager contract manages the bridge between Ethereum and the Gunero network. It creates a public signal that the child-chain follows to manage entries and exits from the child-chain trading ecosystem that the Proof of Authority consensus participants approve as a group. It also allows network participants the ability to control their assets in the child-chain by exiting from the chain's control and returning their tokens back into their own control if the network is experiencing consensus failure or censorship.

Entry (aka Locking)

Property	Value
API	deposit(tokenId)
Who can do it?	owner of tokenId in main-chain
Can be challenged?	No

The Deposit function allows the token's owner to transfer control of the token into the child chain network, where transfer-ability according to the rules of the Gunero network is allowed. This assumes that the Manager contract can assume control of tokenId from the current owner at the time the function was called.

We provide this functionality directly through onERC721Received() in the manager contract, which can be called via the safeTransferFrom() function in the Token contract. Note that this function is not directly implemented due to this reason.

Exit (aka Unlocking)

Property	Value
API	exit(tokenId, ownedBlockNum, txnData, ownerProof, burnProof)
Who can call?	owner of tokenId in plasma-chain at ownedBlockNum
Who can challenge?	No one

The Exit function allows the token's current owner in the Gunero network to exit their token from the Gunero network, removing it's ability to be transferred according to the rules of the network. Due to the "Zero Knowledge" property of Gunero it is not possible to know who the owner is of the token directly, but thanks to the usage of the Simple Merkle Tree (SMT) data structure for the database that Plasma Cash uses (which Gunero is derived from), it is possible to prove the current state of token ownership. We can leverage that in the exit procedure to prove that an exit is valid by asking the owner to "burn" their token on the child chain, resetting the corresponding entry in the plasma-chain's SMT.

Thanks to the "provable computation" property of Gunero's zk-SNARK transactions, it is cryptographically unlikely that anyone besides the owner can actually submit an exit transaction. This means we can eliminate the "challenge period" required in Plasma Cash exit procedures.

A primary use case of the exit procedure in PlasmaRifle is actually an attestation of loss or theft of the physical firearm. This allows a user to declare their token unspendable, and blacklist their firearm from future minting. This also creates a signal for law enforcement and other interested parties to follow the status of the firearm. Any exit will be cancel-able by the attestor within the checkpoint threshold, which is currently 30 days.

Hot Potato! Exit (aka release of ownership) [MVP Only]

Property	Value
API	release(tokenId, signedTxn, merkleProof, txnBlockNum)
Who can call?	past owner of tokenId in plasma-chain at txnBlockNum
Who can challenge?	owner of tokenId in plasma-chain at txnBlockNum can "forward" it

In PlasmaRifle, we introduce the concept of "Hot Potato" exits, which are defined as an exit with a proof of that party spending a specific tokenId and transferring it to someone else, which they publicly announce. This exit is backed by submitting their original transaction, which shows that the transaction was conducted correctly, and no false information was submitted. The "hot potato" exit can only start with the original party who tokenized that firearm by revealing the transaction immediately following the minting of that token. The current "owner" of the token will then have until the checkpoint time period to submit another "hot potato" exit, thereby showing re-transmission of the tokenId to another party and resetting the timer. If the exit is shown to be "final" aka a merkle proof can be submitted against the current root hash that reflects the token is included in the current, the timer is stopped and the last "owner" is now the owner of the token.

This property can allow law enforcement the tools necessary to track down the ownership chain of the firearm in the case of an incident by appealing to the original party who tokenized that firearm, either through a court order or that party's own volition. This is the only way to uniquely determine the current owner of a firearm of interest, and since it is transparent and on-chain can be a mitigating factor against the possibility of "mass surveillance" by law enforcement, since it is not possible to determine overall ownership without private information from each participant in every transaction, information that GunClear does not know.

Key Loss Attestation [MVP Only]

Property	Value
API	recover(oldTokenId, newTokenId)
Who can call?	owner of newTokenId in main-chain
Who can challenge?	owner of oldTokenId in plasma-chain

Since our tokens represent physical assets, we can make one final type of exit, which may be challenge-able. Due to the properties of our application, the loss of physical keys (and no respective backup) will end the ability to trade using our zero-knowledge transfer child chain. That token is thus inaccessible in the child chain because the keys to unlock it are no longer available, so the user will make an attestation (under a new address) that they would have access to that token if they hadn't lost their keys.

That user, which GunClear has some ability to correlate the identities of, makes a claim through that old address to exit the token into GunClear's control. If the claim is challenged, the GunClear authority will remove both identities from the Whitelist, permanently blacklisting that user, and burn those tokens (re-issuing a new token to the last challenger). If the claim goes un-challenged, the token is burned and a new token is minted to that new identity.

This exit has some potential for griefing attacks to valid users that wish to keep their history private. GunClear will therefore be the only party capable of initiating this type of exit, and will gather appropriate materials from the on-boarding party necessary to prove beyond a shadow of a doubt that this exit will be conducted appropriately, and thus may take up to 30 days to conduct this process. This is why regular backups are so important to GunClear users.