-
Notifications
You must be signed in to change notification settings - Fork 1
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 zero-knowledge trading system that the Proof of Authority participants manage through their consensus protocol. It also allows network participants the ability to retain control over 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 ultimately experiencing consensus failure or censorship.
The functionality described below enables tokenized firearm owners to perform these actions.
| 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, which unlocks zero-knowledge transfers according to the rules of the Gunero network.
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.
Due to re-tokenization of the underlying asset in case of loss of access, there may be a removal of the old token from the Gunero network. Since GunClear has no advanced knowledge of ownership in the system, this opens a potential griefing attack of current token owners in the Gunero network.
If the deposit was a re-tokenization of an existing managed asset,
this function starts off the challenge process for the deposit.
For more information, see challengeDeposit(...) below.
| 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.
| 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.
| 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.
Information contained in this wiki is licensed under CC-BY-SA-4.0
Copyright 2018 GunClear