-
Notifications
You must be signed in to change notification settings - Fork 118
What is an anchor?
Anchoring is the embedding of DefiChain blockchain information into the Bitcoin blockchain as transaction data. This embedded record is read back by DefiChain and can be used to verify that a node is on the same chain as in the record. Anchor data includes the DefiChain block height and hash, a link to the previous anchor, if not the first in the anchor chain and the next anchor data creation team. The DefiChain node software has the ability to send Bitcoin transactions, so is able to create these anchors without having to use Bitcoin directly.
Anchoring is a multi-stage process, there are deterministic masternode teams assigned to two different roles in the process, anchor data creation and anchor data confirmation. Interaction with Bitcoin is performed via SPV (Simple Payment verification), anchor data creation, anchor embedding into Bitcoin and Bitcoin embedded anchor data confirmation all require SPV to be enabled in the node.
The anchor data creation team will create and sign anchor data, any user can create and embed an anchor into Bitcoin via the RPC (Remote procedure call) interface, the anchor confirmation team will validate that data, stakers will then pay the accrued anchor reward to the user who created the anchor to compensate for Bitcoin transaction fees. Nodes will then parse the anchor transaction and record the anchor information from that transaction for user reference.
Every 120 blocks, counting from the genesis block, new anchor teams are defined to make sure that teams are made up of currently active members, only masternodes that are currently operating and have staked a block in the last week (7 * 2880 blocks) are used in anchor teams. Two teams are created directly at the end of connecting a new block to the blockchain at the set interval of 120 blocks. Team members are selected randomly but also deterministically. The masternode identifier, stake modifier for the block and a team identifier are hashed, that hash along with the masternode identifier is added to two different maps for the two different teams, the map is the hash to the masternode identifier and is sorted by the hash. The new team members are then selected from the start of those maps.
Team information is stored in the local database for late reference, when it is required to validate data related to those teams.
After every new block the anchor data creation team members will create and sign new anchor data. Anchor data is created every fifthteen blocks, the block height and hash chosen is then three hours further back into the chain and then more blocks until the every the fifthteen block frequency is matched again.
Anchor data consists of the following.
Previous anchor hash - Bitcoin transaction hash that embedded the previous anchor data into Bitcoin, it is used as the anchor identifier. DefiChain height - This is the height of the anchor block chosen. DefiChain hash - The hash of the block at the chosen height. Team data - Data used to identify the anchor data team and blockchain fork.
Team data is twenty bytes that holds a block height and a block hash prefix, this height relates to the anchor creation height and not the height of the anchor found three hours deep into the chain. This then allows us to correctly identify the team that created the anchor data, the block hash prefix lets us check that the anchor data was created on the same chain the node finds itself on, otherwise it will be discarded.
When an anchor is created it is shared with the rest of the network via the Peer-to-Peer messaging layer. Anchor messages hold the anchor data and the signature of the member that created the anchor data. All nodes can relay and validate these messages, but only SPV nodes can validate the previous anchor data, due to this a node creating an anchor must be SPV enabled to fully validate the anchor data provided.
An SPV enabled node can create an anchor as long as anchor data is available and that a quorum of signatures is met, this quorum is 66% of the anchor data creation team size plus one. Each anchor data received is signed by only one team member, the number of anchor data with unique signatures is counted and if quorum is met then that anchor data is used. If quorum is not met and there are multiple instances of anchor data available, then the next instance is checked in descending block height order.
The anchor team is found by extracting the height from the team data field in the anchor data and looking up the team in the locally calculated record of teams at various heights. The signatures created by this team are included in the Bitcoin anchor transaction so that quorum can be checked when getting anchor data from the Bitcoin blockchain.
With valid anchor data the user can then create the anchor, they will need to provide a Bitcoin UTXO (Unspent Transaction Output) to be used to pay for the transaction fee, and the private key to sign the transaction. Change from the Bitcoin transaction will be sent back to the address related to the UTXO. A DefiChain address must also be provided for the DFI reward to be sent to.
With the required information provided the node will create and send the Bitcoin transaction. The transaction is made up of a single user UTXO as input and multiple outputs, the first output of 100,000 Satoshis is to a public address hard coded in the node software used to allow SPV to find a Bitcoin anchor transaction. The second output is OP_RETURN which allows 80 bytes of data in an output that is provably unspendable and will therefore not be included in the UTXO set. The anchor data begins to be embedded in this second output, but as the anchor data is much larger than this, several more outputs are used. There is a Bitcoin policy that only allows 80 bytes of data in an OP_RETURN output, but only one OP_RETURN output per transaction.
To work around this limitation the remaining anchor data is embedded in dummy addresses, addresses hold 20 bytes of data. Anchors on the Bitcoin network use eight of these outputs, total storage of eight outputs and OP_RETURN is 240 bytes. Each of the dummy address outputs require an amount of 330 Satoshis to not be considered dust outputs which would otherwise invalidate the transaction. The final output is the change back to the UTXO address.
SPV enabled nodes will see any transaction added to the Bitcoin blockchain, due to the hard coded address in the node software used in the anchor data transaction. If a transaction using this address is identified as an anchor transaction then some simple validation is performed. This new anchor is then added to pending anchor storage to be fully validated in the context of the blockchain.
Once the blockchain is equal to or above the height defined in the anchor data, then full validation can proceed to confirm that the anchor data relates to the chain the node is on and that it conforms to the anchor creation rules. The anchor data team is looked up using the data embedded in the anchor team data record, the signatures are checked against the team and if quorum is met. If all validation succeeds then an anchor is added to the list of known anchors, this list is only available to SPV enabled nodes.
Anchors form a chain starting from the lowest Bitcoin block height, after the first anchor any subsequent anchor must have the previous top anchor defined in its previous anchor field. There can be several competing anchors, but only a single valid chain of anchors can be formed, this can result in several anchors being marked inactive. If two anchors are found at the same Bitcoin height then the one with the highest DefiChain height wins. Only anchors that are used to form the active anchor chain are rewarded by stakers.
With anchor data read and validated from Bitcoin and anchors created in SPV clients, stakers will pay the anchor reward to the anchor creator. To facilitate this process the anchor confirmation team will send out anchor confirmation messages to the network to reach the staking nodes.
The confirmation team will most likely be made up of masternodes different to the anchor team masternodes. Members of the confirmation team need to have SPV enabled to be able to read the anchor data and create and add anchors from that data to the anchor list. Stakers do not need to have SPV enabled, it is the anchor confirmation messages that provide the staker with all the required anchor information, this is how the active anchors bridge from SPV to non-SPV nodes.
After every anchor transaction confirmation on Bitcoin, the list of active anchors is checked and if there are any unrewarded anchors with six confirmations on the Bitcoin network, then the confirmation team will create and sign an anchor confirmation message. This message contains the following information to be used by stakers.
Bitcoin transaction hash - Anchor transaction hash on the Bitcoin network. Bitcoin transaction height - Anchor transaction height on the Bitcoin network. Reward address - DefiChain address to pay the anchor reward to. DefiChain height - This is the height of the anchor block chosen. DefiChain hash - The hash of the block at the chosen height. Previous anchor height - Height of the last paid anchor in the anchor chain. Previous anchor hash - This hash is Bitcoin transaction hash that embedded the previous anchor data into Bitcoin, it is used as the anchor identifier.
The anchor confirmation message sent over the network will be validated and relayed to other nodes, each node will keep a collection of these messages.
When a staker creates a new block it will lookup the confirmation team currently at the top of the chain, then query the local collection of anchor confirmation messages to find any confirmations signed by the confirmation team. If messages are found and there are enough to meet the required quorum then the anchor reward transaction will be created. This anchor reward transaction embeds all the information defined in the anchor confirmation message and all quorum signatures into an OP_RETURN output. Another output is added with the destination set to the anchor reward address and the amount set to the accrued anchor reward. The embedding of anchor data into the blockchain then sets the anchor record permanently and allows every node to parse that anchor record and maintain a list for reference by the user. Nodes will fully validate the anchor data embedded in the anchor transaction, including the signatures and that quorum is met. If any of this validation fails, then the block containing the anchor transaction will be rejected.