mirror of
https://github.com/pezkuwichain/pezkuwi-fellows.git
synced 2026-05-30 10:31:02 +00:00
bkchr
456 lines
51 KiB
HTML
456 lines
51 KiB
HTML
|
||
<!DOCTYPE HTML>
|
||
<html lang="en" class="polkadot" dir="ltr">
|
||
<head>
|
||
<!-- Book generated using mdBook -->
|
||
<meta charset="UTF-8">
|
||
<title>RFC-0130: JAM Validity + DA Services for Ethereum Optimistic Rollups and Ethereum - Polkadot Fellowship RFCs</title>
|
||
|
||
|
||
<!-- Custom HTML head -->
|
||
|
||
<meta name="description" content="An online book of RFCs approved or proposed within the Polkadot Fellowship.">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
<meta name="theme-color" content="#ffffff">
|
||
|
||
<link rel="icon" href="../favicon.svg">
|
||
<link rel="shortcut icon" href="../favicon.png">
|
||
<link rel="stylesheet" href="../css/variables.css">
|
||
<link rel="stylesheet" href="../css/general.css">
|
||
<link rel="stylesheet" href="../css/chrome.css">
|
||
<link rel="stylesheet" href="../css/print.css" media="print">
|
||
|
||
<!-- Fonts -->
|
||
<link rel="stylesheet" href="../FontAwesome/css/font-awesome.css">
|
||
<link rel="stylesheet" href="../fonts/fonts.css">
|
||
|
||
<!-- Highlight.js Stylesheets -->
|
||
<link rel="stylesheet" href="../highlight.css">
|
||
<link rel="stylesheet" href="../tomorrow-night.css">
|
||
<link rel="stylesheet" href="../ayu-highlight.css">
|
||
|
||
<!-- Custom theme stylesheets -->
|
||
<link rel="stylesheet" href="../theme/polkadot.css">
|
||
|
||
</head>
|
||
<body class="sidebar-visible no-js">
|
||
<div id="body-container">
|
||
<!-- Provide site root to javascript -->
|
||
<script>
|
||
var path_to_root = "../";
|
||
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "polkadot" : "polkadot";
|
||
</script>
|
||
|
||
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
||
<script>
|
||
try {
|
||
var theme = localStorage.getItem('mdbook-theme');
|
||
var sidebar = localStorage.getItem('mdbook-sidebar');
|
||
|
||
if (theme.startsWith('"') && theme.endsWith('"')) {
|
||
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
||
}
|
||
|
||
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
||
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
||
}
|
||
} catch (e) { }
|
||
</script>
|
||
|
||
<!-- Set the theme before any content is loaded, prevents flash -->
|
||
<script>
|
||
var theme;
|
||
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
||
if (theme === null || theme === undefined) { theme = default_theme; }
|
||
var html = document.querySelector('html');
|
||
html.classList.remove('polkadot')
|
||
html.classList.add(theme);
|
||
var body = document.querySelector('body');
|
||
body.classList.remove('no-js')
|
||
body.classList.add('js');
|
||
</script>
|
||
|
||
<input type="checkbox" id="sidebar-toggle-anchor" class="hidden">
|
||
|
||
<!-- Hide / unhide sidebar before it is displayed -->
|
||
<script>
|
||
var body = document.querySelector('body');
|
||
var sidebar = null;
|
||
var sidebar_toggle = document.getElementById("sidebar-toggle-anchor");
|
||
if (document.body.clientWidth >= 1080) {
|
||
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
||
sidebar = sidebar || 'visible';
|
||
} else {
|
||
sidebar = 'hidden';
|
||
}
|
||
sidebar_toggle.checked = sidebar === 'visible';
|
||
body.classList.remove('sidebar-visible');
|
||
body.classList.add("sidebar-" + sidebar);
|
||
</script>
|
||
|
||
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
||
<div class="sidebar-scrollbox">
|
||
<ol class="chapter"><li class="chapter-item expanded affix "><a href="../introduction.html">Introduction</a></li><li class="spacer"></li><li class="chapter-item expanded affix "><li class="part-title">Newly Proposed</li><li class="spacer"></li><li class="chapter-item expanded affix "><li class="part-title">Proposed</li><li class="chapter-item expanded "><a href="../proposed/0111-pure-proxy-replication.html">RFC-0111: Pure Proxy Replication</a></li><li class="chapter-item expanded "><a href="../proposed/0112-compress-state-response-message-in-state-sync.html">RFC-0112: Compress the State Response Message in State Sync</a></li><li class="chapter-item expanded "><a href="../proposed/0114-secp256r1-hostfunction.html">RFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signatures</a></li><li class="chapter-item expanded "><a href="../proposed/0117-unbrick-collective.html">RFC-0117: The Unbrick Collective</a></li><li class="chapter-item expanded "><a href="../proposed/0121-iterable-referenda-tracks.html">RFC-0121: Iterable Referenda Tracks</a></li><li class="chapter-item expanded "><a href="../proposed/0123-pending-code-as-storage-location-for-runtime-upgrades.html">RFC-0123: Introduce :pending_code as intermediate storage key for the runtime code</a></li><li class="chapter-item expanded "><a href="../proposed/0124-extrinsic-version-5.html">RFC-0124: Extrinsic version 5</a></li><li class="chapter-item expanded "><a href="../proposed/0125-xcm-asset-metadata.html">RFC-0125: XCM Asset Metadata</a></li><li class="chapter-item expanded "><a href="../proposed/0126-introduce-xcq.html">RFC-0126: Introduce XCQ(Cross Consensus Query)</a></li><li class="chapter-item expanded "><a href="../proposed/0130-JAM-Service-for-Validating-Ethereum-Optimistic-Rollups.html" class="active">RFC-0130: JAM Validity + DA Services for Ethereum Optimistic Rollups and Ethereum</a></li><li class="spacer"></li><li class="chapter-item expanded affix "><li class="part-title">Approved</li><li class="chapter-item expanded "><a href="../approved/0001-agile-coretime.html">RFC-1: Agile Coretime</a></li><li class="chapter-item expanded "><a href="../approved/0005-coretime-interface.html">RFC-5: Coretime Interface</a></li><li class="chapter-item expanded "><a href="../approved/0007-system-collator-selection.html">RFC-0007: System Collator Selection</a></li><li class="chapter-item expanded "><a href="../approved/0008-parachain-bootnodes-dht.html">RFC-0008: Store parachain bootnodes in relay chain DHT</a></li><li class="chapter-item expanded "><a href="../approved/0010-burn-coretime-revenue.html">RFC-0010: Burn Coretime Revenue</a></li><li class="chapter-item expanded "><a href="../approved/0012-process-for-adding-new-collectives.html">RFC-0012: Process for Adding New System Collectives</a></li><li class="chapter-item expanded "><a href="../approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html">RFC-0013: Prepare Core runtime API for MBMs</a></li><li class="chapter-item expanded "><a href="../approved/0014-improve-locking-mechanism-for-parachains.html">RFC-0014: Improve locking mechanism for parachains</a></li><li class="chapter-item expanded "><a href="../approved/0022-adopt-encointer-runtime.html">RFC-0022: Adopt Encointer Runtime</a></li><li class="chapter-item expanded "><a href="../approved/0026-sassafras-consensus.html">RFC-0026: Sassafras Consensus Protocol</a></li><li class="chapter-item expanded "><a href="../approved/0032-minimal-relay.html">RFC-0032: Minimal Relay</a></li><li class="chapter-item expanded "><a href="../approved/0042-extrinsics-state-version.html">RFC-0042: Add System version that replaces StateVersion on RuntimeVersion</a></li><li class="chapter-item expanded "><a href="../approved/0043-storage-proof-size-hostfunction.html">RFC-0043: Introduce storage_proof_size Host Function for Improved Parachain Block Utilization</a></li><li class="chapter-item expanded "><a href="../approved/0045-nft-deposits-asset-hub.html">RFC-0045: Lowering NFT Deposits on Asset Hub</a></li><li class="chapter-item expanded "><a href="../approved/0047-assignment-of-availability-chunks.html">RFC-0047: Assignment of availability chunks to validators</a></li><li class="chapter-item expanded "><a href="../approved/0048-session-keys-runtime-api.html">RFC-0048: Generate ownership proof for SessionKeys</a></li><li class="chapter-item expanded "><a href="../approved/0050-fellowship-salaries.html">RFC-0050: Fellowship Salaries</a></li><li class="chapter-item expanded "><a href="../approved/0056-one-transaction-per-notification.html">RFC-0056: Enforce only one transaction per notification</a></li><li class="chapter-item expanded "><a href="../approved/0059-nodes-capabilities-discovery.html">RFC-0059: Add a discovery mechanism for nodes based on their capabilities</a></li><li class="chapter-item expanded "><a href="../approved/0078-merkleized-metadata.html">RFC-0078: Merkleized Metadata</a></li><li class="chapter-item expanded "><a href="../approved/0084-general-transaction-extrinsic-format.html">RFC-0084: General transactions in extrinsic format</a></li><li class="chapter-item expanded "><a href="../approved/0091-dht-record-creation-time.html">RFC-0091: DHT Authority discovery record creation time</a></li><li class="chapter-item expanded "><a href="../approved/0097-unbonding_queue.html">RFC-0097: Unbonding Queue</a></li><li class="chapter-item expanded "><a href="../approved/0099-transaction-extension-version.html">RFC-0099: Introduce a transaction extension version</a></li><li class="chapter-item expanded "><a href="../approved/0100-xcm-multi-type-asset-transfer.html">RFC-0100: New XCM instruction: InitiateAssetsTransfer</a></li><li class="chapter-item expanded "><a href="../approved/0101-xcm-transact-remove-max-weight-param.html">RFC-0101: XCM Transact remove require_weight_at_most parameter</a></li><li class="chapter-item expanded "><a href="../approved/0103-introduce-core-index-commitment.html">RFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receipts</a></li><li class="chapter-item expanded "><a href="../approved/0105-xcm-improved-fee-mechanism.html">RFC-0105: XCM improved fee mechanism</a></li><li class="chapter-item expanded "><a href="../approved/0107-xcm-execution-hints.html">RFC-0107: XCM Execution hints</a></li><li class="chapter-item expanded "><a href="../approved/0108-xcm-remove-testnet-ids.html">RFC-0108: Remove XCM testnet NetworkIds</a></li><li class="chapter-item expanded "><a href="../approved/0122-alias-origin-on-asset-transfers.html">RFC-0122: Asset transfers can alias XCM origin on destination to original origin</a></li><li class="spacer"></li><li class="chapter-item expanded affix "><li class="part-title">Stale</li><li class="chapter-item expanded "><a href="../stale/0000-rewards.html">RFC-0000: Validator Rewards</a></li><li class="chapter-item expanded "><a href="../stale/0004-remove-unnecessary-allocator-usage.html">RFC-0004: Remove the host-side runtime memory allocator</a></li><li class="chapter-item expanded "><a href="../stale/0006-dynamic-pricing-for-bulk-coretime-sales.html">RFC-0006: Dynamic Pricing for Bulk Coretime Sales</a></li><li class="chapter-item expanded "><a href="../stale/0009-improved-net-light-client-requests.html">RFC-0009: Improved light client requests networking protocol</a></li><li class="chapter-item expanded "><a href="../stale/0015-market-design-revisit.html">RFC-0015: Market Design Revisit</a></li><li class="chapter-item expanded "><a href="../stale/0034-xcm-absolute-location-account-derivation.html">RFC-34: XCM Absolute Location Account Derivation</a></li><li class="chapter-item expanded "><a href="../stale/0035-conviction-voting-delegation-modifications.html"> RFC-0035: Conviction Voting Delegation Modifications</a></li><li class="chapter-item expanded "><a href="../stale/0044-rent-based-registration.html">RFC-0044: Rent based registration model</a></li><li class="chapter-item expanded "><a href="../stale/0054-remove-heap-pages.html">RFC-0054: Remove the concept of "heap pages" from the client</a></li><li class="chapter-item expanded "><a href="../stale/0070-x-track-kusamanetwork.html">RFC-0070: X Track for @kusamanetwork</a></li><li class="chapter-item expanded "><a href="../stale/0073-referedum-deposit-track.html">RFC-0073: Decision Deposit Referendum Track</a></li><li class="chapter-item expanded "><a href="../stale/0074-stateful-multisig-pallet.html">RFC-0074: Stateful Multisig Pallet</a></li><li class="chapter-item expanded "><a href="../stale/0077-increase-max-length-of-identity-pgp-fingerprint-value.html">RFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytes</a></li><li class="chapter-item expanded "><a href="../stale/0088-broker-pallet-slashable-deposit-purchaser-reputation-reserved-cores.html">RFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker pallet</a></li><li class="chapter-item expanded "><a href="../stale/00xx-secondary-marketplace-for-regions.html">RFC-0001: Secondary Market for Regions</a></li><li class="chapter-item expanded "><a href="../stale/00xx-smart-contracts-coretime-chain.html">RFC-0002: Smart Contracts on the Coretime Chain</a></li><li class="chapter-item expanded "><a href="../stale/0102-offchain-parachain-runtime-upgrades.html">RFC-0000: Feature Name Here</a></li><li class="chapter-item expanded "><a href="../stale/0106-xcm-remove-fees-mode.html">RFC-0106: Remove XCM fees mode</a></li><li class="chapter-item expanded "><a href="../stale/0120-referenda-confirmation-by-candle-mechanism.html">RFC-0120: Referenda Confirmation by Candle Mechanism</a></li><li class="chapter-item expanded "><a href="../stale/RFC-114 Adjust Tipper Track Confirmation Periods.html">RFC-114: Adjust Tipper Track Confirmation Periods</a></li><li class="chapter-item expanded "><a href="../stale/TODO-stale-nomination-reward-curve.html">RFC-TODO: Stale Nomination Reward Curve</a></li></ol>
|
||
</div>
|
||
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
|
||
</nav>
|
||
|
||
<!-- Track and set sidebar scroll position -->
|
||
<script>
|
||
var sidebarScrollbox = document.querySelector('#sidebar .sidebar-scrollbox');
|
||
sidebarScrollbox.addEventListener('click', function(e) {
|
||
if (e.target.tagName === 'A') {
|
||
sessionStorage.setItem('sidebar-scroll', sidebarScrollbox.scrollTop);
|
||
}
|
||
}, { passive: true });
|
||
var sidebarScrollTop = sessionStorage.getItem('sidebar-scroll');
|
||
sessionStorage.removeItem('sidebar-scroll');
|
||
if (sidebarScrollTop) {
|
||
// preserve sidebar scroll position when navigating via links within sidebar
|
||
sidebarScrollbox.scrollTop = sidebarScrollTop;
|
||
} else {
|
||
// scroll sidebar to current active section when navigating via "next/previous chapter" buttons
|
||
var activeSection = document.querySelector('#sidebar .active');
|
||
if (activeSection) {
|
||
activeSection.scrollIntoView({ block: 'center' });
|
||
}
|
||
}
|
||
</script>
|
||
|
||
<div id="page-wrapper" class="page-wrapper">
|
||
|
||
<div class="page">
|
||
<div id="menu-bar-hover-placeholder"></div>
|
||
<div id="menu-bar" class="menu-bar sticky">
|
||
<div class="left-buttons">
|
||
<label id="sidebar-toggle" class="icon-button" for="sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
||
<i class="fa fa-bars"></i>
|
||
</label>
|
||
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
||
<i class="fa fa-paint-brush"></i>
|
||
</button>
|
||
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
||
<li role="none"><button role="menuitem" class="theme" id="polkadot">Polkadot</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="light">Light</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
||
</ul>
|
||
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
||
<i class="fa fa-search"></i>
|
||
</button>
|
||
</div>
|
||
|
||
<h1 class="menu-title">Polkadot Fellowship RFCs</h1>
|
||
|
||
<div class="right-buttons">
|
||
<a href="../print.html" title="Print this book" aria-label="Print this book">
|
||
<i id="print-button" class="fa fa-print"></i>
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div id="search-wrapper" class="hidden">
|
||
<form id="searchbar-outer" class="searchbar-outer">
|
||
<input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
||
</form>
|
||
<div id="searchresults-outer" class="searchresults-outer hidden">
|
||
<div id="searchresults-header" class="searchresults-header"></div>
|
||
<ul id="searchresults">
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
||
<script>
|
||
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
||
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
||
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
||
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
||
});
|
||
</script>
|
||
|
||
<div id="content" class="content">
|
||
<main>
|
||
<p><a href="https://github.com/polkadot-fellows/RFCs/pull/130">(source)</a></p>
|
||
<p><strong>Table of Contents</strong></p>
|
||
<ul>
|
||
<li><a href="#rfc-0130-jam-validity--da-services-for-ethereum-optimistic-rollups-and-ethereum">RFC-0130: JAM Validity + DA Services for Ethereum Optimistic Rollups and Ethereum</a>
|
||
<ul>
|
||
<li><a href="#background">Background</a></li>
|
||
<li><a href="#motivation">Motivation</a></li>
|
||
<li><a href="#requirements">Requirements</a></li>
|
||
<li><a href="#stakeholders">Stakeholders</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#jam-service-design-for-validating-eth-l2-orus--ethereum">JAM Service Design for Validating ETH L2 ORUs + Ethereum</a>
|
||
<ul>
|
||
<li><a href="#overview">Overview</a></li>
|
||
<li><a href="#refine">Refine:</a></li>
|
||
<li><a href="#accumulate">Accumulate</a>
|
||
<ul>
|
||
<li><a href="#transfer">Transfer</a></li>
|
||
<li><a href="#beefy">Beefy</a></li>
|
||
<li><a href="#service-poc-implementation">Service PoC Implementation</a></li>
|
||
<li><a href="#gas--storage-considerations">Gas + Storage Considerations</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#compatibility">Compatibility</a></li>
|
||
<li><a href="#testing-security-and-privacy">Testing, Security, and Privacy</a></li>
|
||
<li><a href="#future-directions-and-related-material">Future Directions and Related Material</a></li>
|
||
<li><a href="#drawbacks-alternatives-and-unknowns">Drawbacks, Alternatives, and Unknowns</a></li>
|
||
<li><a href="#acknowledgements">Acknowledgements</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<h1 id="rfc-0130-jam-validity--da-services-for-ethereum-optimistic-rollups-and-ethereum"><a class="header" href="#rfc-0130-jam-validity--da-services-for-ethereum-optimistic-rollups-and-ethereum">RFC-0130: JAM Validity + DA Services for Ethereum Optimistic Rollups and Ethereum</a></h1>
|
||
<div class="table-wrapper"><table><thead><tr><th></th><th></th></tr></thead><tbody>
|
||
<tr><td><strong>Start Date</strong></td><td>26 October 2024 (Updated: November 5, 2024)</td></tr>
|
||
<tr><td><strong>Description</strong></td><td>JAM Service for Validating Optimistic Rollups and Ethereum</td></tr>
|
||
<tr><td><strong>Authors</strong></td><td>Sourabh Niyogi</td></tr>
|
||
<tr><td><strong>Abstract</strong></td><td>JAM’s mission as a <em>rollup host</em> can be extended from validating Polkadot rollups to validating Ethereum optimistic rollups (ORUs) as well as Ethereum itself. We outline a design for a JAM Service to validating ORUs + Ethereum using a similar approach to Polkadot rollups anticipated in the CoreChains service. The design involves verifying state witnesses against account balances, nonces, code, and storage, and then using this state to re-execute block transactions, all within the service's <code>refine</code> operation; then, these validated ETH L1+L2 blocks are stored on-chain in service's <code>accumulate</code> operation. This JAM service is readily implementable with already available tools that fits seamlessly into JAM’s refine-accumulate service architecture: (a) Geth’s Consensus API, which outputs state witnesses for Ethereum and its dominant ORU ecosystems (OP Stack and Arbitrum Nitro), and (b) Rust-based EVM interpreter <code>revm</code> that should be compilable to PolkaVM with <code>polkatool</code>. This allows Ethereum+ETH L2 ORU users to benefit from JAM’s high computational and storage throughput. The JAM service enables rollup operators to choose JAM Services over other rollup service providers or to enhance their use of Ethereum for improved Web3 user experience, ultimately to provide validity proofs faster. Furthermore, Ethereum itself can be validated by the same JAM service, providing additional verification for ORU L2 commitments posted to Ethereum across all Ethereum forks.</td></tr>
|
||
</tbody></table>
|
||
</div>
|
||
<h2 id="background"><a class="header" href="#background">Background</a></h2>
|
||
<p>The Gray Paper suggests a design for applying the same audit protocol from Polkadot's parachain validation service to ETH rollups: "<em>Smart-contract state may be held in a coherent format on the JAM chain so long as any updates are made through the 15kb/core/sec work results, which would need to contain only the hashes of the altered contracts’ state roots.</em>" This proposal concretely outlines a JAM service to do this for two top non-Polkadot optimistic rollup platforms: <a href="https://stack.optimism.io/">OP Stack</a> and <a href="https://docs.arbitrum.io/how-arbitrum-works/arbos/introduction">ArbOS</a> as well as, ostentatiously, Ethereum itself.</p>
|
||
<p>Optimistic rollups use centralized sequencers and have no forks, creating an illusion of fast finality while actually relying on delayed fraud proofs. Optimistic rollups are termed "optimistic" because they assume transactions are valid by default, requiring fraud proofs on Ethereum L1 if a dispute arises. Currently, ORUs store L2 data on ETH L1, using EIP-4844's blob transactions or similar DA alternatives, just long enough to allow for fraud proof submission. This approach, however, incurs a cost: a 7-day exit window to accommodate fraud proofs. JAM Service can reduce the dependence on this long exit window by validating L2 optimistic rollups as well as the L1.</p>
|
||
<h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
|
||
<p>JAM is intended to host rollups rather than serve end users directly.</p>
|
||
<p>A JAM service to validate Optimistic Rollups and Ethereum will expand JAM's service scope to and enhance their appeal with JAM's high throughput capabilities for both DA and computational resources.</p>
|
||
<p>Increasing the total addressable market for rollups to include non-Polkadot rollups will increase CoreTime demand, making JAM attractive to both existing and new optimistic rollups with higher cross-validation.</p>
|
||
<p>A JAM Service that can certify ORUs state transitions as being <strong>valid</strong> and <strong>available</strong> can deliver ecosystem participants (e.g. CEXs, bridge operators, stablecoin issuers) potentially improved user experiences that is <em>marketable</em>. With popular CEXes (Coinbase, Kraken) adopting OP Stack, any improvement is highly visible to retail users, making ETH ORUs "Secured by Polkadot JAM Chain".</p>
|
||
<h2 id="requirements"><a class="header" href="#requirements">Requirements</a></h2>
|
||
<ol>
|
||
<li>Securing optimistic rollups with a JAM Service should be practical and require minimal changes by the ORU operator.</li>
|
||
<li>Securing Polkadot rollups with a JAM Service should <strong>not</strong> be affected.</li>
|
||
</ol>
|
||
<h2 id="stakeholders"><a class="header" href="#stakeholders">Stakeholders</a></h2>
|
||
<ol>
|
||
<li>Optimistic Rollup Operators seeking low-latency high throughput validation services and very high throughput DA</li>
|
||
<li>Web3 developers wanting to create applications on optimistic rollups secured by JAM</li>
|
||
<li>DOT Holders aiming to increase CoreTime demand from non-Polkadot rollups</li>
|
||
</ol>
|
||
<h1 id="jam-service-design-for-validating-eth-l2-orus--ethereum"><a class="header" href="#jam-service-design-for-validating-eth-l2-orus--ethereum">JAM Service Design for Validating ETH L2 ORUs + Ethereum</a></h1>
|
||
<h2 id="overview"><a class="header" href="#overview">Overview</a></h2>
|
||
<p>Ethereum L1 and ETH L2 Rollups produce a sequence of blocks ${\bf B}$ with headers ${\bf H}$. The header ${\bf H}$ contains a parent header hash ${\bf H}<em>p$ and a state root ${\bf H}</em>{r}$, which represents the global state after applying all block transactions. The transactions trie root is unnecessary; validating the state trie root alone is sufficient for validating rollups.</p>
|
||
<p>This JAM Service strategy, as hinted in the JAM Gray Paper, aggregates <strong>state witnesses</strong> in a chain of work packages. The <code>refine</code> operation takes these state witnesses of an optimistic rollup's blocks and verifies them against the prior block's state root ${\bf H}_r$.</p>
|
||
<p>The rollup operator submits headers, blocks and state witnesses in a chain of work packages $..., p_{n-1}, p_{n}, p_{n+1}, ...$ corresponding to the rollup chain, which may typically but not necessarily form a chain. The strategy advocated is to <em>preemptively</em> validate all blocks in possible forks under the assumption that cores (and CoreTime) are plentiful, rather than seek a canonical finalized chain head. Instead of relying on a <em>promise</em> that each state root is correct unless proven otherwise with ORU fraud proofs, JAM validates a block using state witnesses for each and validates the posterior state root ${\bf H}_r$ by reexecuting the block's transactions.</p>
|
||
<p>In JAM, the 2 key operations are <code>refine</code> and <code>accumulate</code>:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The <code>refine</code> operation happens "off-chain" with a small subset of validators (2 or 3) via an almost entirely <em>stateless</em> computation based the contents of the work package:</p>
|
||
<ul>
|
||
<li>(a) validating state witness proofs $\Pi$ against the <em>prior</em> state root ${\bf H}_r$:
|
||
<ul>
|
||
<li>account balances</li>
|
||
<li>account nonces</li>
|
||
<li>contract code</li>
|
||
<li>storage values</li>
|
||
</ul>
|
||
</li>
|
||
<li>(b) given the block's transactions (and potential incoming deposits from L1 and withdrawals to L1), applying each the transaction generating a new posterior state root ${\bf H}_r$, which if it matches that contained in ${\bf H}$, is a <strong>proof of validity.</strong></li>
|
||
</ul>
|
||
<p>The Consensus API of <code>geth</code> , used in popular optimistic rollup platforms of OP Stack and Arbitrum Nitro, are well-suited to generate the state witnesses, and enables 1(a).</p>
|
||
<p>A EVM interpreter (<code>revm</code>) compiled in PolkaVM using <code>polkatool</code> enables 1(b).</p>
|
||
<p>The results of <code>refine</code> are inputs to <code>accumulate</code> -- representing a set of valid blocks.</p>
|
||
</li>
|
||
<li>
|
||
<p>The <code>accumulate</code> simply stores which block hashes/header hashes have been validated, solicits the block and header for storage in JAM DA.</p>
|
||
</li>
|
||
</ol>
|
||
<p>The primary goal is to have L2 ORUs and L1 Ethereum blocks fully available in JAM DA and modeled as "valid", even if those blocks are tentative / non-canonical. This enables JAM to certify blocks as being valid as fast as possible in the finalized on the JAM Chain <em>on any fork</em>.</p>
|
||
<p>A secondary goal is to establish finality against L1 using the state roots posted from L2 on L1, but we put this secondary goal aside for now as Ethereum finality (12.8 minutes) is generally slower than JAM finality (1-2 mins). This secondary goal can definitely be supported by the Attestations from the Beacon chain, given ordered accumulation and these attestations, JAM finalize the entirely of Ethereum's rollups handily.</p>
|
||
<h2 id="refine"><a class="header" href="#refine">Refine:</a></h2>
|
||
<h4 id="key-input-work-packages"><a class="header" href="#key-input-work-packages">Key Input: Work Packages</a></h4>
|
||
<p>Using the <code>newPayloadWithWitnessV4</code> method of <code>ConsensusAPI</code> added in Sept 2024, comprehensive state witnesses in this <a href="https://github.com/ethereum/go-ethereum/commit/9326a118c7c074a6c719b381033845c47c1168f5">commit</a> enables JAM to be validate blocks full nodes of Ethereum, OP Stack and ArbOS in a <strong>stateless</strong> way.</p>
|
||
<p>Since OP Stack and ArbOS basically use historically leading <code>geth</code> to power their own execution engine, the ConsensusAPI of <code>geth</code> can be used to get a <a href="https://github.com/ethereum/go-ethereum/blob/master/core/state/statedb.go#L139">Stateless witness</a> during tracing within the <a href="https://github.com/ethereum/go-ethereum/blob/master/core/tracing/hooks.go#L40-L49">core/tracing package of StateDB</a>. At a high level, this Consensus API has a set of <a href="https://github.com/ethereum/go-ethereum/blob/master/core/tracing/hooks.go#L192-L195">State Change Hooks</a> that are called for <a href="https://github.com/ethereum/go-ethereum/blob/master/core/tracing/hooks.go#L157-L167">OnBalanceChange, OnNonceChange, OnCodeChange, OnStorageChange hooks</a> during a replay of block execution, which culminates in <a href="https://github.com/ethereum/go-ethereum/blob/master/eth/catalyst/api.go#L929">InsertBlockWithoutSetHead returning a set of state witness proofs</a>. The end result is a state witnesses / proofs $\Pi$ of storage values that can be verified in against the prior block's state root ${\bf H}_r$.</p>
|
||
<p>Then, given a block ${\bf B}$ and these verified proofs $\Pi$ (verified against the prior state root ${\bf H}_r$, a complete state transition to validate a new posterior state root contained within ${\bf B}$ can be thoroughly conducted. A well-tested and highly stable Rust EVM interpreter <a href="https://github.com/bluealloy/revm">revm</a> should be compilable to PolkaVM with <code>polkatool</code> (see <a href="https://forum.polkadot.network/t/building-jam-services-in-rust/10161">Building JAM Services in Rust</a>). Then, using the provided <em>verified</em> <code>state_witnesses</code> the revm "in-memory" database can be set up with <code>AccountInfo</code> nonce, balance, and code (see <a href="https://github.com/bluealloy/revm/blob/bbc8d81dbe2a6a4d184e32fa540e1c4e248a65c9/crates/statetest-types/src/account_info.rs#L9-L15">here</a>) as well as storage items, conceptually like:</p>
|
||
<pre><code>use revm::{Database, EVM, AccountInfo, U256, B160};
|
||
|
||
fn initialize_evm_with_state(evm: &mut EVM<impl Database>, state_witnesses: HashMap<B160, AccountInfo>) {
|
||
// Set up each account's state in the EVM's database.
|
||
for (address, account_info) in state_witnesses {
|
||
// Insert nonce/balance/code
|
||
evm.database().insert_account(address, account_info);
|
||
// Insert storage if available
|
||
for (storage_key, storage_value) in account_info.storage {
|
||
evm.database().insert_storage(address, storage_key, storage_value);
|
||
}
|
||
}
|
||
}
|
||
</code></pre>
|
||
<p>With the prior state fully initialized in memory via <code>initialize_evm_with_state</code>, we run through the EVM execution of the transactions of the block. Each transaction will interact with the pre-loaded state witnesses in the database. Because <code>revm</code> is very well maintained and stable, it already supports the latest <a href="https://github.com/ethereum/tests/tree/develop/GeneralStateTests">Ethereum State Transition tests</a> for individual transactions and given a block of transactions (or indeed a chain of blocks) can compute the posterior state root ${\bf H}_r$ for that block (or a chain of blocks). The block is valid if the block execution of <code>revm</code> results in the same state root ${\bf H}_r$ as contained in the header ${\bf H}$ and in the block ${\bf B}$ (or a chain of blocks). If it does, the <code>refine</code> code outputs both hashes, which will be solicited on chain in <code>accumulate</code> (and can be supplied by anyone, whether the ORU or some third-party).</p>
|
||
<p>In JAM's <code>refine</code> code, work package content is as follows:</p>
|
||
<div class="table-wrapper"><table><thead><tr><th>JAM Refine</th><th>Content</th></tr></thead><tbody>
|
||
<tr><td><em>Work Package</em> $p_n \in \mathbb{P}$</td><td>Data submitted by ORU operator for validation of $N$ blocks, not necessarily in a chain, potentially multiple blocks at different block heights</td></tr>
|
||
<tr><td><em>Payload</em> ${\bf y}$</td><td>Chain ID (e.g., 10, 42161, etc.), start and end block numbers expected in extrinsics</td></tr>
|
||
<tr><td><em>Extrinsics</em> $\bar{{\bf x}}$</td><td>Header Hash $H({\bf H})$ , Block Hash $H({\bf B})$, Header ${\bf H}$, block ${\bf B}$, and State Witnesses $\Pi$ against <em>prior</em> state root ${\bf H}_r$ for each block</td></tr>
|
||
<tr><td><em>Work Items</em> ${\bf w} \in \mathbb{I}$</td><td>$N$ <em>Prior</em> state roots ${\bf H}_r$, one for each extrinsic ${\bf x} \in \bar{\bf x}$</td></tr>
|
||
<tr><td><em>Work Result</em> ${\bf r}$</td><td>Tuples $(i,t,H({\bf H}),H({\bf B}))$ of Block number $i$, timestamp $t$, header hash and block hash</td></tr>
|
||
</tbody></table>
|
||
</div>
|
||
<p>Refine's operations are as follows:</p>
|
||
<ol>
|
||
<li><strong>Authorize</strong>. Check for authorization ${\bf o}$.</li>
|
||
<li><strong>Verify State Witnesses.</strong> For each element ${\bf x} \equiv (H({\bf H}), H({\bf B}), {\bf H}, {\bf B}, \Pi)$ in extrinsics $\bar{{\bf x}}$ and the prior state root ${\bf H}_r$ in the work item:
|
||
<ul>
|
||
<li>Verify each state witness $\pi \in \Pi$ and initialize <code>AccountInfo</code> objects for all verified proofs $a_{b}, a_{n}, a_c, a_{s}(k,v)$ for balance, nonce and storage proofs</li>
|
||
<li>If any proof $\pi \in \Pi$ fails verification, skip to the next extrinsic, considering the block <em>invalid</em>.</li>
|
||
<li>If all proofs $\pi \in \Pi$ pass verification, proceed to next step.</li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>Apply Transactions.</strong> Initialize <code>revm</code> with the value of <code>AccountInfo</code> to apply all transactions For the block transactions ${\bf B}_T$ , , and derive the chain, with ${\bf H}_p$ matching the previous extrinsic $H({\bf H})$, except for the first header, which must match the previous 2.
|
||
<ul>
|
||
<li>Use the state root ${\bf H}_r$, .</li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>Output Worked Results: Verified Proof of Validity.</strong>. For each validated block, output a tuple $(i, t, H({\bf H}), H({\bf B}))$ of block number $i$, the block timestamp $t$, and the two hashes in the extrinsic ${\bf x} \in \bar{\bf x}$: $H({\bf H})$ and $H({\bf B})$.</li>
|
||
</ol>
|
||
<p>The refine process uses <em>no</em> host functions (not even <code>historical_lookup</code>) as chain-hood of the blocks is not pursued within <code>refine</code>. As detailed in GP, work results in guaranteed work reports from the above <code>refine</code> are assured, audited, and judged following the ELVES protocol. JAM finalizes its audited blocks via GRANDPA voting and can be exported to other chains with BEEFY.</p>
|
||
<p>Optimistic rollups, including OP Stack and ArbOS, use Ethereum's Merkle Patricia Trie to commit to state data on each block. See <a href="https://i.sstatic.net/OdfkP.jpg">this architecture diagram</a> for a refresher. The state root ${\bf H}_r$ is a cryptographic commitment to the entire rollup state at that block height. The state witness from the rollups API enable the ORU to prove that specific storage values exist against the prior state root.</p>
|
||
<p>Due to <code>refine</code> use of a EVM interpreting compiling to PolkaVM, this is basically reexecuting the block. The state witnesses $\Pi$ enable <code>refine</code> to be stateless, consistent with JAM/ELVES design principles.</p>
|
||
<p>For simplicity, we consider <em>100%</em> of state witnesses from a single block, with zero consideration to the extremely likely possibility that the blocks may form a chain with no forks. Given a chain of blocks, a more compressed approach would be to only include $\pi \in \Pi$ that actually new storage values in the chain of blocks. This would enable a reduced work package size as well as a smaller number of proof verifications in <code>refine</code>. We set this obvious optimization aside for now.</p>
|
||
<h2 id="accumulate"><a class="header" href="#accumulate">Accumulate</a></h2>
|
||
<p>The <code>accumulate</code> operation is an entirely synchronous <em>on-chain</em> operation performed by all JAM Validators (rather than <em>in-core</em> as with <code>refine</code>). Computation is carried out first by the JAM Block Author and the newly authored block sent to all Validators.</p>
|
||
<p>In this JAM Service Design, the <code>accumulate</code> operation indexes the tuple from <code>refine</code> by block number and solicits both the block and header data. When provided (by the ORU but potentially anyone), this ensures that ETH L1+L2 data necessary to validate ETH L1+ORU L2s is fully available in JAM DA. At this time, we do not concern ourselves with chain-hood and finality, and instead model all L1 + L2 forks. However, we use a simple $f$ parameter to limit to the on-chain storage to blocks within a certain time range, putatively 28 days.</p>
|
||
<h4 id="on-chain-storage-of-rollup-state"><a class="header" href="#on-chain-storage-of-rollup-state">On-chain Storage of Rollup State</a></h4>
|
||
<p>For simplicity, for each blockchain we have a separate service with a unique chain_id (e.g Ethereum 1, Optimism 10, Base 8453, Arbitrum 42161, etc.) with its own service storage. The service stores on-chain service storage the following key components:</p>
|
||
<ul>
|
||
<li>all blocks and headers, which are solicited to be added to JAM DA via <code>solicit</code> and after a 28 day window, removed from JAM DA via <code>forget</code>. Blocks and headers held in preimage storage in ${\bf a}<em>{\bf p}$ ; preimage availability in JAM DA is represented in lookup storage ${\bf a}</em>{\bf l}$ via the preimage hash of both the block hash $H({\bf B})$ and header hash $H({\bf H})$.</li>
|
||
<li>an index of block numbers $i$ into tuples of block hash, header hash and timestamp ($t, H({\bf H}), H({\bf B}))$, held in storage ${\bf a}_s$, potentially more than one per block number</li>
|
||
<li>a simple $f$ parameter to support <code>forget</code> operations</li>
|
||
</ul>
|
||
<p>The function of the above on-chain service storage is to represent <strong>both</strong> of the following:</p>
|
||
<ul>
|
||
<li>the <code>refine</code> validation has successfully completed for a set of blocks <em>and</em></li>
|
||
<li>the block and headers are available in JAM's DA</li>
|
||
</ul>
|
||
<p>as well as bound storage costs to a reasonable level using $f$.</p>
|
||
<h4 id="key-process"><a class="header" href="#key-process">Key Process</a></h4>
|
||
<div class="table-wrapper"><table><thead><tr><th>JAM Accumulate</th><th>Content</th></tr></thead><tbody>
|
||
<tr><td><em>Work Results</em></td><td>Tuple of $(i, t, H({\bf H}), H({\bf B}))$, see <code>refine</code></td></tr>
|
||
</tbody></table>
|
||
</div>
|
||
<ol>
|
||
<li>
|
||
<p>For each block number $i$ in the tuple, perform the following operations:</p>
|
||
<ul>
|
||
<li><code>solicit</code> is called for both hashes in the work results. The ORU operator is expected to provide both preimages but any community member could do so.</li>
|
||
<li><code>read</code> is called for block number $i$ to check if there are any previous blocks stored</li>
|
||
<li>if there aren't, initialize the value for $i$ to be $(H({\bf H}), H({\bf B}))$</li>
|
||
<li>if there are, append an additional two hashes $(H({\bf H}), H({\bf B}))$</li>
|
||
<li><code>write</code> the updated value, which may be multiple pairs of hashes if there are forks for the chain.</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>To bound storage growth to just the validated blocks that are within a certain window of around 28 days, we also:</p>
|
||
<ul>
|
||
<li><code>read</code> $f$ from service key 0, which holds $(i,t)$, the oldest block $i$ that has been solicited and the time $t$ it was solicited, but may now be outside the window of 28 days</li>
|
||
<li>if $t$ is older than 28 days, then if ${\bf a}_l$ is <em>Available</em> (note there are 2 states) then issue <code>forget</code> and advance $(i,t)$</li>
|
||
<li>repeat the above until either the oldest block is less than 28 days ago or gas is nearly exhausted</li>
|
||
<li><code>write</code> $f$ back to storage if changed</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Accumulation output is the newest blockhash $H({\bf B})$ solicited in step 1, which is included in the BEEFY root in JAM's Recent History.</p>
|
||
</li>
|
||
</ol>
|
||
<p>Under normal operations, the above process will result in a full set of validated blocks and header preimages being in JAM's DA layer. An external observer of the JAM Chain can, for the last 28 days, check for validity of the chain in any fork, whether finalized or unfinalized on ETH L1 or ETH L2 ORU.</p>
|
||
<h3 id="transfer"><a class="header" href="#transfer">Transfer</a></h3>
|
||
<p>Transfer details concerning fees of storage balance are not considered at this time. A full model appears to necessitate a clear interface between JAM and CoreTime as well as a model of how this service can support a single vs. multiple Chain IDs. Naturally, all service fees would be in DOT rather than ETH on L2.</p>
|
||
<p>Multiple service instantiations under different CoreTime leases may be envisioned for each rollup, but a set of homogenous ORU rollups to support sync/async models by the same ORU operator could also be supported.</p>
|
||
<h3 id="beefy"><a class="header" href="#beefy">Beefy</a></h3>
|
||
<p>Following the BEEFY protocol, JAM's own state trie aggregates work packages' accumulate roots into its own recent history $\beta$, signed by JAM validators. BEEFY’s model allows JAM's state to be verified on Ethereum and other external chains without needing all JAM Chain data on the external chain.
|
||
All rollups, whether built on Substrate or optimistic turned cynical, are committed into this state, supporting cross-ecosystem proofs using Merkle trees as today.</p>
|
||
<p>To support this goal, the accumulate result is the last block hash, last header hash, or last state root as suitable to match Polkadot rollup behavior.</p>
|
||
<h3 id="service-poc-implementation"><a class="header" href="#service-poc-implementation">Service PoC Implementation</a></h3>
|
||
<p>This JAM Service can be implemented in Rust using <code>polkatool</code> and tested on a <a href="https://github.com/jam-duna/jamtestnet">JAM Testnet</a> by early JAM implementers.</p>
|
||
<p>With a full node of Ethereum, Optimism, Base, and Arbitrum, real-world work packages can be developed and tested offline and then in real-time with a dozen cores at most.</p>
|
||
<h3 id="gas--storage-considerations"><a class="header" href="#gas--storage-considerations">Gas + Storage Considerations</a></h3>
|
||
<p>JAM's gas parameters for PVM instructions and host calls have not been fully developed yet. Combining the CoreChain and this Ethereum+ORU validation services will provide valuable data for determining these parameters.</p>
|
||
<p>The gas required for <code>refine</code> is proportional to:</p>
|
||
<ul>
|
||
<li>the size of $\Pi$ submitted in a work package</li>
|
||
<li>the amount of gas used by ${\bf B}_T$, which is embedded in the ${\bf B}$ itself</li>
|
||
</ul>
|
||
<p>The proof generation of $\Pi$ is not part of refine and do not involve the sequencer directly; instead this would be done by a neighboring community validator node. In addition, I/O of reading/writing state tries are believed to dominate ordinary ORU operation but are also part in the refine operation.</p>
|
||
<p>The gas required for <code>accumulate</code> is proportional to the number of blocks verified in <code>refine</code> , which result in <code>read</code> , <code>write</code> , and <code>solicit</code> and <code>forget</code> operations. It is believed that accumulate's gas cost is nominal and poses no significant issue. However, storage rent issues common to all blockchain storage applies to the preimages, which is explicitly tallied in service ${\bf a}$. Fortunately, this is upper-bounded by the number of blocks generated in a 28-day period.</p>
|
||
<h2 id="compatibility"><a class="header" href="#compatibility">Compatibility</a></h2>
|
||
<h4 id="coretime"><a class="header" href="#coretime">CoreTime</a></h4>
|
||
<p>Instead of ETH, rollups would require DOT for CoreTime to secure their rollup. However, rollups are not locked into JAM and may freely enter and exit the JAM ecosystem since work packages do not need to start at genesis.</p>
|
||
<p>Different rollups may need to scale their core usage based on rollup activity. JAM's connectivity to CoreTime is expected to handle this effectively.</p>
|
||
<h4 id="hashing"><a class="header" href="#hashing">Hashing</a></h4>
|
||
<p>Currently, preimages are specified to use the Blake2b hash, while Ethereum rollup block hashes utilize Keccak256. This is an application level concern trivially solved by the preimage provider responding to preimage announcements by Blake2b hash instead of Keccak256.</p>
|
||
<h2 id="testing-security-and-privacy"><a class="header" href="#testing-security-and-privacy">Testing, Security, and Privacy</a></h2>
|
||
<p>The described service requires expert review from security experts familiar with JAM, ELVES, and Ethereum.</p>
|
||
<p>The ELVES and JAM protocols are expected to undergo audit with the 1.0 ratification of JAM.</p>
|
||
<p>It is believed that the use of <code>revm</code> is safe due to its extensive coverage of Ethereum State + Block tests, but this may require careful review.</p>
|
||
<p>The <code>polkatool</code> compiler has not battletested by comparision.</p>
|
||
<p>The Consensus API generating state witnesses is likely mature but a relatively new addition to the <code>geth</code> code base.</p>
|
||
<p>The proposal introduces no new privacy concerns.</p>
|
||
<h2 id="future-directions-and-related-material"><a class="header" href="#future-directions-and-related-material">Future Directions and Related Material</a></h2>
|
||
<p>It is natural to bring in finality from Ethereum using Attestations from the Beacon chain to finalize validated blocks as they become available from Ethereum and ETH ORU L2s enabled by this type of service. A "ETH Beacon Service" bringing in the Altair Light Client data would enable the Ethereum Service, all ETH ORUs to compute the canonical chain. This would use the "Ordered Accumulation" capabilities of JAM, reduce the storage footprint to just those blocks that are actually finalized in the L2 against an Ethereum finalized checkpoint.</p>
|
||
<p>As JAM implementers move towards conformant implementations in 2025, which support gas modeling and justify performance improvements, a proper model of storage costs and fees will be necessary.</p>
|
||
<p>JAM enables a semi-coherent model for non-Polkadot rollups, starting with optimistic rollups as described here. A similar service may be envisioned for mature ZK rollup ecosystems, though there is not as much more in <code>refine</code> than to verify the ZKRU proof. A JAM messaging service between ORUs and ZKRUs may be highly desirable. This can be done in a separate service or simply by adding in <code>transfer</code> code with <code>read</code> and <code>write</code> operations in service storage incoming and outgoing mailboxes.</p>
|
||
<p>The growth of optimistic rollup platforms, led by OP Stack with CEXes (Coinbase and Kraken) and ArbOS, threatens JAM's viability as a rollup host. Achieving JAM's rollup host goals may require urgency to match the speed at which these network effects emerge.</p>
|
||
<p>On the other hand, if JAM Services are developed and put in production in 2025, JAM Services can validate all of Ethereum as well as Polkadot rollups.</p>
|
||
<h2 id="drawbacks-alternatives-and-unknowns"><a class="header" href="#drawbacks-alternatives-and-unknowns">Drawbacks, Alternatives, and Unknowns</a></h2>
|
||
<p>Alongside Ethereum DA (via EIP-4844), numerous DA alternatives for rollups exist: Avail, Celestia, Eigenlayer. ORUs rely primarily on fraud proofs, but they require a lengthy 7-day window for these "fraud proofs." The cynical rollup model offers significant UX improvements by eliminating this "exit window," commonly 7 days.</p>
|
||
<p>This JAM Service does not turn optimistic rollups into cynical rollups. A method to do so is not known.</p>
|
||
<h2 id="acknowledgements"><a class="header" href="#acknowledgements">Acknowledgements</a></h2>
|
||
<p>We are deeply grateful for the ongoing encouragement and feedback from Polkadot heavyweights (Rob Habermeier, Alistair Stewart, Jeff Burdges, Bastian Kocher), Polkadot fellows, fellow JAM Implementers/Service Builders, and the broader community.</p>
|
||
|
||
</main>
|
||
|
||
<nav class="nav-wrapper" aria-label="Page navigation">
|
||
<!-- Mobile navigation buttons -->
|
||
<a rel="prev" href="../proposed/0126-introduce-xcq.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
||
<i class="fa fa-angle-left"></i>
|
||
</a>
|
||
|
||
<a rel="next prefetch" href="../approved/0001-agile-coretime.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
||
<i class="fa fa-angle-right"></i>
|
||
</a>
|
||
|
||
<div style="clear: both"></div>
|
||
</nav>
|
||
</div>
|
||
</div>
|
||
|
||
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
||
<a rel="prev" href="../proposed/0126-introduce-xcq.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
||
<i class="fa fa-angle-left"></i>
|
||
</a>
|
||
|
||
<a rel="next prefetch" href="../approved/0001-agile-coretime.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
||
<i class="fa fa-angle-right"></i>
|
||
</a>
|
||
</nav>
|
||
|
||
</div>
|
||
|
||
|
||
|
||
|
||
<script>
|
||
window.playground_copyable = true;
|
||
</script>
|
||
|
||
|
||
<script src="../elasticlunr.min.js"></script>
|
||
<script src="../mark.min.js"></script>
|
||
<script src="../searcher.js"></script>
|
||
|
||
<script src="../clipboard.min.js"></script>
|
||
<script src="../highlight.js"></script>
|
||
<script src="../book.js"></script>
|
||
|
||
<!-- Custom JS scripts -->
|
||
|
||
|
||
</div>
|
||
</body>
|
||
</html>
|