RFC: Towards a sustainable decentralized bridging model

[guidiaz]

Where we are

At the time of writing, a simple but operational centralized bridging approach is undertaken by the Witnet Foundation (WF), following this architecture:

Being simple as it it, and despite the obvious disadvantages, the centralized bridge:

• Requires no block relay from Witnet to the EVM chain, so there's no need to worry about who'd pay for this.
• WF subsidizes the cost in wits for every single data request, so a requester to the Witnet Request Board (WRB) only pays for the cost of reporting back the result from the Witnet side-chain.
• Upon response, the requester gets the Witnet Data Request transaction hash (ie. drTxHash) that got posted from the bridge and actually solved the data request. This drTxHash can be used as subjective proof (e.g. by using the Witnet explorer, for instance).
• No dispute windows are involved, so latency for getting a finalized result is minimal.

Where we would like to be

The high-level architecture for a fully decentralized bridging model would ideally look like this:

However, there are several cryptoeconomic concerns to tackle when designing a decentralized bridge between Witnet and any other side-chain with smart-contracts capability:

1. Instant finality of data request results, and blocks containing them, relayed from the Witnet side-chain could get prohibitively expensive, unless some optimizations, latency and complexity are introduced in the Witnet/side-chain interaction protocol. Even if doing so, an abrupt and sustained gas price increase on the side-chain, or witcoin price on the Witnet side, would possibly make pending data requests posted to the WRB going astray for an undetermined period of time.

2. While a data request intrinsically rewards the Witnet nodes contributing to its resolution, the Witnet-protocol contemplates no (obvious) mechanism for rewarding whoever takes the role to perform a block relay into any specific side-chain. It's not obvious neither whether the block relay should be systematically performed, even in the cases where no data requests (relayed from a specific side-chain) were actually solved during a series of consecutive blocks.

High-level design decisions taken so far

As to minimize gas expenditure, and penalize any eventual attempt to tamper results from data requests, a Non-acquiescent Permissioned Optimistic Bridge design is being considered. In this approach, any data reported from the Witnet side-chain will open a dispute window in which any "fishermen" could openly prove either result malleability, or reluctancy to report from the expected-to-be reporter. If no dispute is triggered, reported data will eventually be assumed as valid and finalized.

However, there are some assumptions, limitations and design decisions for this Optimisitc approach that could well be argued, and perhaps reconsidered:

• Repudiant Non-acquiescent Permissioned Optimistic WRB:

  • Data results would be expected to include reference to a pre-relayed superblock => This obligates the Witnet Block Relay contract (WRB) to keep an up-to-date verified sequence of Witnet superblocks.
  • Only the Witnet Foundation would be able report data results in the first instance => Imho, this would be a major drawback, as the WF would be the only entity in the whole Witnet ecosystem with compelling reasons to yield side-chain native-coins from witcoins (either being these witcoins sovereign to the WF, mined or eventually acquired on cryptomarkets).
  • As the WF could just refuse/fail to insert a DR into Witnet, any DR could well go astray for ever => The client smart contract would have no clue to whether a DR is being processed, or if it will ever be.

• Unsustainable Non-acquiescent Permissioned Optimistic WBR:

  • It's assumed that every Witnet superblock contains at least one DR from every actively supported side-chain. => This would be far from realisitc whenever a new side-chain is just integrated w/ Witnet, and also in most of currently supported side -chains at the moment.
  • Again, only the WF is enabled to report superblocks in the first instance. => While "fishermen" could well be incentivized to dispute any malleability, or reluctancy to report, the main issue here is that there's no clear reward mechanism planned for whoever may be in charge of reporting a block relay in first instance.
  • It's also assumed that irreconcilable superblock could be eventually reached, in which case the WBR would need to be redeployed again. => The deployment of the WBR is not a fully trustless process, as a new commonly-accepted genesis block seed would need to be provided every single time.

My proposal

On the high-level design

Straight to the point, let's follow an Non-repudiant Acquiescent Permissionless Optimistic design for the WRB, and a Sustainable Semi-acquiescent Permissioned Optimistic design for the WBR. More elaborately:

1. A permissionless design for the WRB implies that: (a) any bridge node with the capability to interact with a specific side-chain (not necessarily EVM-compatible), would be eligible to insert into Witnet any DR posted to that side-chain's WRB instance; (b) only the bridge node that actually got selected to insert into Witnet a sie-chain-bound DR will have the chance to report in first instance the DR result back to that side-chain (and eventually claim the side-chain-reward), unless it refused to do so before some grace period of time, in which case any other "fisherman" bridge node could do so instead.

2. The acquiescency of the WRB implies that reporting either a proof-of-inclusion, or a DR result, will systematically refer to a block yet-to-be included within a superblock era. It implies also that reporting nodes won't be able to claim side-chain-rewards from solved DRs until the correspondent superblocks are included, and finalized, on the WBR side.

3. The semi-acquiescency of a permissioned WBR implies that there would be no obligation for the block relayer to report a Witnet superblock unless it contained a DR bound to this specific side-chain, or the required gas for batch-reporting previous "empty" superblocks (with no DRs bound to this specific side-chain) gets higher than certain threshold percentage of the maximum gas per block limit of that specific side-chain.

4. The sustainability of a permissioned WBR would be reached by (partially/fully) substracting cumuled sunk costs of current and previous block relays from the "extra fees" (on the side-chain side) of all DRs included within superblock, upon its finalization. To avoid black-hole situations, the WF could still pay for sunk-costs in case-by-case scenarios, like bootstrapping recently integrated side-chain awaiting to get some traction.

5. The non-repudiation on the WRB could be accomplished by formally restricting the maximum Witnet epoch on which a DR can get inserted into the Witnet chain.

On the Witnet protocol

• Let data requests be composed by three well-defined payload parts: the "Retrieval" payload (containing sources, reduce-maps, aggregators and filters), the "Attestation" paramaters (eg: number of witnesses, witnessing quorum, witnet reward, ...), and an (optional) "Delivery" part, containing these new parameters:

  • delivery-side-chain-type and delivery-side-chain-id values, as to bind a DR to a specific side-chain external to Witnet (not necessarily an EVM-compatible chain);

  • a delivery-epoch-not-after value, as to formally restrict the maximum Witnet epoch number at which a side-chain-bound DR could get eventually inserted into the Witnet chain; this value would also be used like a nonce value to any "Retrieval" x "Attestation" params combination, as to avoid the same side-chain-bound DR payload to get inserted more than once (w/ eventually conflicting results) during its resolution & finalization windows, protecting therefore against front-running attacks from mallicious actors on both Witnet side-chain sides.

• Let any DR-related transaction in Witnet be indexed by any of these hashes:

  • the drRetrievalHash, calculated as SHA256 of the Retrieval CBOR-encoded bytecode;
  • the drAttestationHash, calculated as SHA256 of the Attestation CBOR-encoded bytecode;
  • the drQueryHash (currently known also as drOutputHash), calculated as SHA256 of the concatenated CBOR-encoded bytecodes of both Retrieval and Attestation params;
  • the drHash, calculated as SHA256 of the concatenated CBOR-encoded bytecodes of the Retrieval, Attestation and Delivery params (if any).

*For backward-compatibility reasons, a DR not bound to any specific side-chain would have "Delivery" fields set to zero. If delivery fields are zeroed out, the protocol should allow insertion of DRs referring the same drHash. If delivery fields are not zero, the protocol must avoid insertion of DRs having the same drHash. *~

• Let a Witnet block miner decide when to include a side-chain-bound DR insert transaction after applying RepPoe on current epoch number, and the drHash, if current epoch number is lesser than the DR's delivery-epoch-not-after, or if delivery fields of the DR happened to be zeroed out.

Bridge nodes would be incentivized to early-adopt newly integrated side-chains, as that could help them to gain reputation faster. They would be also incentivized to stake more wits as to have chances to convert those wits into a preferred selection of side-chain native-coins.

• Let a DR tally transaction refer to the drHash value, instead of referring the drQueryHash value.

• Extend/modify the Superblock struct:

  • Add a list of side-chains (type+id) referred by DRs during the superblock era, if any (it could be empty).
  • For every non-empty side-chain:
    • dr_txs_sidechain_root of the Merkle tree containing all data request transactions within the superblock era that refered this side-chain;
    • dr_tally_txs_sidechain_root of the Merkle tree containing all data request tally transactions within the superblock era that refered this side-chain;
    • array of hashes of those blocks during the superblock era that included dr transactions and/or dr tally transactions that refered this side-chain (there should be at least one element).
  • Current data_request_root and tally_root fields would possibly not be needed anymore.
  • Use a Verkle tree, instead of a Merkle tree, for computing the ars_root field.

On the Solidity interfaces

Witnet Request Board

• The WRB would be bound to an immutable reference to an (adapated) instance of a Witnet Data Requests registry (see RFC: Having a Witnet Data Requests singleton registry #265).

• When posting a new query, the client may specify a timelimit for the underlying data request to get inserted into the Witnet side-chain. If not specified, the WRB would establish a default value.

• The WRB would provide helper methods as to calculate a Witnet epoch from a regular timestamp, a Witnet epoch estimation from a block number on the side-chain, among others that may become handy for setting a query's proper timelimit.

• The identifier of a data request posted to the WRB will be the drHash of the underlying data request.

• When reporting a legit result, a deposit same as maximum gas cost required by an eventual full-proof reporting (assuming double tx.gasprice) needs to be collateralized, while specifying the following parameters, apart from the result itself:

  • (a) the drHash of the underlying data request that's being solved by the tally;
  • (b) the drTallyTxHash, drTallyTxBlockHash and drTallyTxCommitBlockEpoch of the tally transaction;
  • (c) the drTxHash, drTxBlockHash, drTxBlockEpoch and drTxSigner of the data request transaction bound to the drHash;
  • and (d), a signature of all previous parameters, as to prove that the reporter identity is the same as the one that inserted the data request into the Witnet side-chain.

• The WRB would provide methods to dissect a query's reward on: (a) the "base fee", that pays for the underlying data request expenses on Witnet; (b) the "report fee", that pays for side-chain gas required upon result reporting; and (c) the "extra fee", which should be appealing enough for bridge nodes to accept insertion of data requests. Let's be aware that these values could be substantially altered by how the gas price on the side-chain side, and the price of witcoin ($WIT) quoted on side-chain native-coins, evolve during dispute/finalization windows.

• The WRB would allow bridge nodes to openly report if no bridge node accepted to include the data request before the specified timelimit. The reporter would still need to stake a deposit same as maximum gas cost required by an eventual full-proof report (applying double tx.gasprice), while eventually getting the deposit, the report fee and one share of the "superblock reward pool". Both the extra and base fee of the repudiated data request would contribute in this case to the superblock reward pool.

• Upon finalization of a superblock era, the extra fees of all solved data requests~, as well as the extra and base fees of repudiated data requests,~ will sum up to the so-called "superblock reward pool before block relay". The block relay cost of the correspondent superblock will be substracted from this amount, resulting in the "superblock_reward_pool", from which all true reporters will happen to have one share, including the block relayer.

• Disputed/disputing nodes proven to be true will be granted to withdraw:

  • (a) total staked collateral from disputer(s);
  • (b) the "report fee" of the data request (in all cases);
  • (c) the "base fee" if the data request was not included;
  • and (d), one share of the "superblock reward pool",

Witnet Block Relay

• The WBR would keep an ACL of authorized first-instance relayers.

• When reporting a legit superblock era, a deposit same as maximum gas cost required by an eventual full-proof reporting (assuming double tx.gasprice) needs to be colletaralized, while specifying the following parameters:

  • (a) the superblock index and hash;
  • (b) ordered array of "last_block"s of all previous superblocks not containing any side-chain-specific DRs since last finalized superblock containing side-chain-specific DRs, always including "last_block" of previously finalized superblock w/ DRs as first element, and this superblock's "last_block" as last element;
  • (c) array of blocks within current superblock era containing either side-chain-bound DR txs, or DR tally txs, if any;
  • (d) if (c) is not empty, the merkle roots of all "dr_txs_root"s and all "dr_tally_txs_root"'s of blocks within this superblock;
  • (e) the signing committee size and the Verkle root of the ARS members included into this superblock's "last_block".
  • (f) whether the relayer renounces to its share to the "superblock block reward" if any.

• Fishermen nodes may fully report, or dispute, a legit report, only if: (a) the first-instance reporter lies on its report, as soon as it detects so; or (b), no first-instance reporter reports a superblock containing side-chain-related DR txs, before the end of next superblock.

• A first-instance relayer may retract on the latest legit (or full) report if: (a) no dispute is open over that superblock; (b) current epoch is beyond the era of previous report; and (c) no later superblock has been reported yet. A retraction implies providing proof (full report), but no extra collateral will be required.

• Upon finalization of a superblock era, the block relayer will manage to withdraw collaterals (the one paid by itself, as well as those eventually paid by false-disputers), the actual cost of reporting the legit result, and one share of the "superblock reward pool". Should the "superblock reward pool before block relay" amount not be enough for covering block relay expenses, the WBR contract will account for cumuled debt that may eventually be redeemed on future reports by same block relayer.

• The WBR would enable anyone to cancel debt on a block relayer.

• A reported superblock won't be considered to be finalized until the next reported superblock reaches (at least) the Reconciling window.