DOP Rollup
Last updated
Last updated
DOP Rollup consensus bridges between application layer and blockchain layer. The underlying protocol allows connecting to web2 platforms using APIs/SDKs and web3 infrastructures using smart contracts. The inter-network processing preserves the integrity of transaction and processing in a hybrid version of optimistic rollup.
The key design is to maintain traceability and allowing transactions proposals to submit proofs upon strong demand. This can be indicated by staking or the presence of staked tokens of the nodes, and network participants and constantly gain benefits by processing real world transactions. We call this "Proof-of-Real-Usage"
Each transaction is submitted with a priority indicator to express its urgency and importance. Please see Redemption Gas for more details
Step 0: Before any transaction submission, the processing entities should guarantee that CAP (consumer authorization proof) can be provided when demanded. Possible ways of guarantee this includes: pre-generate, partial generation, custodial services, account abstraction, delegation. Future CAP may become more complex on generation or validation to satisfy additional requirements, however this does not change the processing framework.
Step 1: Application Endpoints submit the transaction directly to Authorizer or delegate an Operator to submit for them. This allows easier on-boarding for general network users. Step 2: Authorizer node broadcasts the transaction it planned to process. It may choose whether to provide CAP directly depending on the transaction priority.
Step3: Authorizer node returns a Domin transaction hash (dotxId) to Operator node.
Step 4: If some nodes suspect the broadcasted transaction is invalid, they can propose a challenge within the challenging period. For operator nodes they will have to provide additional stake for the challenge to prevent overwhelming challenges.
Step 5: The corresponding Authorizer node activates the CAP generation process, and broadcast to the network for inspection.
Step 6: Authorizer nodes validates CAP and vote for pass/fail on the transaction. Pass: Challenge proposer suffers stake loss or slashing due to additional work imposed on others. The processing nodes will be allocated an extra reward on top of original network reward. Fail: All processing nodes cannot receive reward. Authorizer will be slashed of their staked tokens.
Step 7: Upon vote passing or expiring or challenge period, the transaction is regarded to be valid and the corresponding Operator and Authorizer receives their reward allocation. Authorizer signals the corresponding Operator to handle post-transation processing.
Step 8: Authorizer sends blockchain transactions to target chain at according to transaction priority.
Step 9: Authorizer broadcasts the blockchain transaction hash (txHash) with the Domin transation hash (dotxHash) to Domin network.
Operators and Applications can listen to blockchain or include the submitted information in future authroization on open data use
