👮‍♂️Security

Cross-rollup Security Model

Soiler's mission is distinctively tailored to address the unique challenges encountered in cross-rollup scenarios, diverging from the predominant focus on cross-chain transactions. Unlike cross-chain endeavors primarily dedicated to safeguarding transactions across disparate chains and averting 51% attacks, cross-rollup initiatives leverage the collective Ethereum data layer within each rollup, inherently alleviating the threat of a 51% attack. Building upon this premise, the cross-rollup mechanism pioneered by Soiler seamlessly inherits the robust security attributes inherent to Ethereum Layer 2.

Security Mechanism in Transaction: Arbitration

In scenarios where either the Sender or the Maker initiates a transaction that breaches the protocol and engages in malicious conduct, the party responsible for instigating such behavior is termed the Challenger, while the other party involved in the transaction takes on the role of the Challenged. In such instances, both parties are afforded the opportunity to establish the legitimacy of the transaction in a cost-effective manner by leveraging zero-knowledge proofs and smart contracts integrated within the system. These tools empower the parties to furnish evidence and affirm the integrity of the transaction, all the while upholding efficiency and curbing expenses.

To thwart such malicious actions, we've devised an innovative Arbitration mechanism, empowering Senders to address transaction issues swiftly if they don't receive their assets within a reasonable timeframe.

Should Senders fail to receive their assets on the destination network promptly, they can initiate the arbitration process, provided they furnish transaction proof validating their transaction's legitimacy.

In response, Makers can opt to present evidence showcasing the transfer's occurrence or ongoing progress on the destination network. If Makers furnish the requisite transaction evidence to the Sender, they won't incur any losses.

However, in the event Makers are unable to provide the necessary proof, the Sender will receive a full refund for the transaction. Moreover, the Sender will also be entitled to a portion of the surplus margin associated with that transaction from the Maker. This ensures that Senders are duly compensated for any inconvenience or delay arising from transaction failures.

Three contacts are deployed in the network to validate the transaction in arbitration.

• MDC Contract (Maker Deposit Contract): Holds excess margin makers deposits and handles the compensation for Senders.

• EBC Contract (Event Binding Contract): to verify the correspondence between the source and the target transactions.

• ZK-SPV (Zero-Knowledge Simple Payment Verification): Utilise zero-knowledge proof technology to demonstrate the existence and validity of the cross-rollup transactions. Existence refers to both the source and target transactions that can be verified on Layer1 and they indeed took place on the respective L2s. Validity involves confirming the user's intent behind the source transaction and ensuring that the outcome of the maker's payment in the destination transaction adheres to predetermined regulations.

MDC, EBC, and the ZK-SPVs are implemented on a domain that accommodates smart contracts within the Ethereum ecosystem. The chart below illustrates how these three smart contracts work in the Arbitration flow.