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?	Yes, see challengeDeposit(...) below

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.

Deposit Challenge [MVP Only]

Property	Value
API	challengeDeposit(oldTokenId, newTokenId, ownerData, ownerProof)
Who can call?	owner of oldTokenId in main-chain
Who can challenge?	No one

Since our tokens represent physical assets, someone can deposit a new tokenId, which may be linked to an older tokenId already tracked in the Plasma-chain. We allow this because the owner of the token in the Plasma-chain could have lost access to their keys, so we need a method for them to recover access to trading the asset. deposit(...) therefore represents an attestation that the owner had control over the old token before losing access to their keys, which may not be the true state of that token (the owner could have lied). The actual owner of that token will then have to "re-assert" their ownership of that asset through a challenge to that user's attestation. This has some potential for griefing attacks to valid users that wish to keep their history private.

GunClear, as the identity manager of the account's key-holders, has the ability to corroborate this information (that a user attests to a loss of a prior account) and uses it to mint tokens for firearms the user claims to own (but had lost access to). Since GunClear has no advanced knowledge of ownership, it relies on the outcome of this claim process to determine what to do with the relevant accounts involved in the minting new tokens and challenge. It can then take appropriate action by removing those accounts (see Whitelist) and/or tokens (see Token).

See Token Policy for more information on how GunClear handles this information.