The specific implementation of the software layer of the SFT Protocol

The realization of the software layer of the SFT Protocol requires the participation of multiple software modules: pledge contract, multi-signature, asset ownership confirmation, SSV special verifier mechanism, smart contract security, and other multi-module collaborative completion.

4.1 Pledge contract

The contract created at the SFT Protocol contract level to interact with the Stake original chain is called Staking Contract (SC for short). For example, create a FIL-SC to connect FIL and SFT.

4.1.1 Pledge and create a multi-signature address:

When user A who holds FIL initiates a Stake operation on FIL-SC, Staking Contract will first create a multi-signature address, and he will transfer FIL to this address through the FIL original chain. After the transfer is successful, the contract will execute the pledge of the multi-signature address operation, if successful, the tokens will be locked on the original chain.

4.1.2 Proofs:

The SFT protocol will receive a proof (Proofs) of the FIL original chain, and then trigger the contract to generate an equivalent amount of SFT and send it to the Staker. The update of Staking Contract requires the original chain and the SFT protocol to work together. Due to the need to monitor the contract status of each chain, the implementation of the Staking contract has many similarities with the cross-chain mechanism.

4.1.3 Casting:

When the holder initiates a Staking request in the Staking Contract, the generation of the multi-signature account occurs on the SFT protocol. At the same time, the transfer of personal assets to the multi-signature address is completed through the signature of the Stake user. This transfer happens on the original chain. After the contract captures the transfer information, it initiates a Stake request from the multi-signature address to the original chain. After Staking is completed on the original chain, SFT will capture the Stake status of the address on the original chain and verify it. After the verification is successful, the corresponding SFT will be minted on the SFT protocol immediately.

Throughout the process, the SFT protocol interacted with the original chain many times. State monitoring and capture play an important role in the security of the entire protocol. The SFT protocol captures the original state through time delay and multi-pass verification to ensure the ultimate authenticity of the original chain.

4.2 Multi-signature

In order to ensure the unique correspondence between the ownership of Stake assets and SFT, the SFT protocol has designed an intermediate address model.

The asset ownership of this address does not belong to anyone, that is, no one can own the private key of this address. SFT guarantees the asset neutrality of the intermediate address through secure multi-party computing technology and threshold multi-signature technology, ensuring that SFT holders only sign when they initiate redemption. Secure multi-party computing involves privacy and requires the participation of a group of verifiers with special functions in SFT. A certain number of verifiers, called SFTSpecialValidator (SSV) nodes, use their own private keys to sign and transmit them through a secure channel to verify the signature. Validity, and finally realize the recovery of the intermediate address signature. This intermediate address has no private key and is not stored on the SFT protocol. Only when a signature is required, it is signed by the private certificate of the special authenticator. The realization of threshold multi-signature technology realizes that some but not all generators can generate private key signatures.

4.3 Secure Multi-Party Computation

When the holder of SFT initiates the redemption of StakeContract, the multi-signature address needs to create a private key signature during the calculation and generation process, and a dedicated verifier participates. Verifiers transmit calculation results through encrypted channels, and they can mutually verify the results without revealing their private keys.

Secure multi-party computing mainly focuses on how to safely calculate predefined functions without an untrusted third party, and solves the practical problem that the results depend on multi-party data calculations and parties are unwilling to share the original data. Through secure multi-party computation, the final result can be verified without revealing the initial input value to third parties, which is a secure way to unlock and redeem Staking Contract.

4.4 Transfer of Ownership

When the Staking operation is completed, the redemption right of FIL on the multi-signature address is in the hands of the SFT holder. Only SFT holders have the right to redeem the FIL-SC contract. If user A trades SFT to user B, then user A loses the right to redeem the original chain FIL, and the mapping relationship between the FIL of the multi-signature address in the contract and the address of user A also gives B. Willingness to initiate redemption, or trade SFT to others. In this process, the multi-signature address completes multiple rounds of ownership confirmation of the original chain FIL through the signature of a special verifier different from the Polkadot world on SFT, and does not require a block consensus.

4.5 SFT Special Validator (SSV)

The SFT protocol realizes the security and fairness of the verification data through the SSV mechanism.

Different from SFTValidator (SV), SSV is the witness of asset ownership in the SFTStake contract. When a qualified holder initiates a redemption to the contract, a special verifier will participate in the calculation and complete the transfer of assets from the multi-signature address to the personal address through signature. When no redemption operation occurs, the special validator stores its own private key locally, waiting to be called.

A special validator consists of multiple people picked at random. SFT will select N SSVs from SVs through a random algorithm. SFT will randomly select N SSVs to calculate locally and transmit the results through secret channels. After the verification is passed, the participation permission is obtained and saved locally on the server. At the same time, each SSV needs to run a light node of the project supported by StakeContract to verify the transaction status of the original chain. The program is written throughout a dedicated validator client, performing validation automatically.

4.6 SSV Node Verifier Mechanism

In order to ensure the security of redemption data, there are special verifiers in SFT who are grouped in a fixed way. During their respective shifts, a single group of validators completes the generation of multisignal addresses and the storage of keys, and is replaced by a new group after the execution cycle is complete. This ensures the participation of the current validators. A validator term lasts for one epoch (1 epoch is approximately 24 hours). The election of the next set is done in the previous epoch. SFT selects new SSVs from SV candidates through the block rate, Staking ratio, etc. The new SSV will replace the old SSV's private key with its own private key, and at the same time, the system will destroy the relationship established with the old SSV's private key.

4.7 Node Validator Reward and Punishment Mechanism

Due to the importance of special verifiers, SFT has established an incentive and punishment mechanism for them, encouraging positive behaviors such as computing and storage, and punishing negative behaviors such as disconnection and failure to replace them in time. The SFT protocol stipulates that those who participate in address generation, calculation, and signature will receive SFT protocol tokens—DAO incentives. On the other hand, SFT has severe penalties for security issues. SFT will require all verifiers involved in computation and storage to remain online for a specified amount of time. If validators are frequently disconnected, they will be slashed. If the offline time exceeds N hours, the validator will be Jailed and cannot participate in any calculation and storage of the special validator group for a period of time.

4.8 Staking Mechanism for Special Validators

Anyone who holds SFT tokens can apply to be a special certifier of SFT. A special validator needs to pledge DAOToken, which is proportional to the number of Stakes that can be accepted, that is, the more DAOs are mortgaged, the greater the value of Stake asset calculation and storage. This can effectively increase the cost of joint malicious behavior by special validators. The pledged DAO will be incentivized by the system and also a fund pool for system punishment. Due to the particularity of the SFT system, the requirements for special verifiers are relatively strict, and the nodes at the initial stage of going online will gradually open up to attract verifiers.

4.9 Staking contract security

The asset security of Staking Contract in the SFT protocol is guaranteed in various ways.

4.9.1 Asset neutrality :

Staking assets will be locked on the original chain, and their mapping relationship will be recorded in the Staking Contract. The multi-signature address is guaranteed by N SSVs through threshold multi-signal sharing technology. Therefore SC is not controlled by any single third party.

4.9.2 Multi-signature address uses asset mechanism :

Special verifiers are selected by the SFT random algorithm. The verifiers do not know each other, the possibility of collusion becomes smaller, and the asset protection will be dynamically replaced within a certain period of time to ensure safety.

4.9.3 Punishment mechanism :

When validators participate in the calculation and storage of private key signatures, they need to pledge a certain amount of DAO participation. In the event of an attack or illegal act, the pledged DAO will be Slashed and the pledged value can be disposed of. Proportional to the value of the asset. When multiple conditions are combined, the SFT system can effectively penalize certain risk factors. Under the assumption that most people are honest, the assets of the Staking contract can guarantee a certain degree of security.

4.10 Process

The pledge process is as follows. The user first interacts with the SC, and the SC then interacts with the original chain. During this period, in order to make the user's operation simple enough, SC needs to assume the responsibility of interacting with the original chain multiple times. Importantly, SC needs to verify the success of the pledge before distributing SFT to users. Users can redeem the assets on the original chain through the SFT they hold at any time. The modification of the relationship of the SC requires the signature of the SSV, because the record relationship of the asset is on the SC. When a user initiates a redemption, the SC triggers a signature request. After the SSV executes the signature, the SC interacts with the original chain and submits an Unbond/Unstake request. Then, SSV verifies the trustless evidence on the original chain. The SFT used to submit the request will be destroyed when the proof is true.