mirror of
https://github.com/pezkuwichain/pezkuwi-fellows.git
synced 2026-05-30 08:11:01 +00:00
bkchr
409 lines
40 KiB
HTML
409 lines
40 KiB
HTML
|
||
<!DOCTYPE HTML>
|
||
<html lang="en" class="polkadot" dir="ltr">
|
||
<head>
|
||
<!-- Book generated using mdBook -->
|
||
<meta charset="UTF-8">
|
||
<title>RFC-0127: JAM Service for Validating Ethereum Optimistic Rollups - 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="chapter-item expanded "><a href="../new/0125-xcm-asset-metadata.html">RFC-0125: XCM Asset Metadata</a></li><li class="chapter-item expanded "><a href="../new/0126-introduce-xcq.html">RFC-0126: Introduce XCQ(Cross Consensus Query)</a></li><li class="chapter-item expanded "><a href="../new/0127-JAM-Service-for-Validating-Ethereum-Optimistic-Rollups.html" class="active">RFC-0127: JAM Service for Validating Ethereum Optimistic Rollups</a></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/0102-offchain-parachain-runtime-upgrades.html">RFC-0000: Feature Name Here</a></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/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/0120-referenda-confirmation-by-candle-mechanism.html">RFC-0120: Referenda Confirmation by Candle Mechanism</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/RFC-114 Adjust Tipper Track Confirmation Periods.html">RFC-114: Adjust Tipper Track Confirmation Periods</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/0089-flexible-inflation.html">RFC-0089: Flexible Inflation</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/0106-xcm-remove-fees-mode.html">RFC-0106: Remove XCM fees mode</a></li><li class="chapter-item expanded "><a href="../stale/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="../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/127">(source)</a></p>
|
||
<p><strong>Table of Contents</strong></p>
|
||
<ul>
|
||
<li><a href="#rfc-0127-jam-service-for-validating-ethereum-optimistic-rollups">RFC-0127: JAM Service for Validating Ethereum Optimistic Rollups</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">JAM Service Design</a>
|
||
<ul>
|
||
<li><a href="#overview">Overview</a></li>
|
||
<li><a href="#refine">Refine:</a>
|
||
<ul>
|
||
<li><a href="#key-validation-process-storage-proofs">Key Validation Process: Storage Proofs</a></li>
|
||
</ul>
|
||
</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>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<h1 id="rfc-0127-jam-service-for-validating-ethereum-optimistic-rollups"><a class="header" href="#rfc-0127-jam-service-for-validating-ethereum-optimistic-rollups">RFC-0127: JAM Service for Validating Ethereum Optimistic Rollups</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</td></tr>
|
||
<tr><td><strong>Description</strong></td><td>JAM Service for Securing Ethereum Optimistic Rollups</td></tr>
|
||
<tr><td><strong>Authors</strong></td><td>Sourabh Niyogi</td></tr>
|
||
<tr><td><strong>Abstract</strong></td><td>JAM's <em>rollup host</em> function can be extended from Polkadot rollups to non-Polkadot rollups. We outline the design of a JAM service capable of securing Ethereum <em>optimistic</em> rollups, such as OP Stack and ArbOS. This service transforms optimistic rollups to cynical rollups, allowing users to benefit from the finality and high throughput of JAM, alongside JAM's anticipated messaging service. This JAM service's competitive advantage enables rollup operators to choose JAM/Polkadot over Ethereum or other rollup providers. A precise design for the service's refine-accumulate function is outlined, using tools already available.</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 <strong>only the hashes of the altered contracts’ state roots</strong>.</em>" This proposal concretely addresses 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>.</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.</p>
|
||
<p>This approach, however, incurs a cost: a 7-day exit window to accommodate fraud proofs. JAM Service can eliminate this long exit window by validating optimistic rollups.</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 secure JAM service for Optimistic Rollups will expand JAM's service scope to include optimistic rollups and enhance their appeal with JAM's finality.</p>
|
||
<p>This expanded focus on rollups will increase CoreTime demand, making JAM attractive to both existing and new optimistic rollups by reducing exit windows.</p>
|
||
<p>This JAM Service converts optimistic rollups into cynical rollups, delivering a user experience advantage that is marketable. With popular CEXes (Coinbase, Kraken) adopting OP Stack, this improvement is highly visible to retail users, turning ORUs into CRUs "Secured by JAM" for a competitive edge.</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 shorter exit windows, lower costs, higher scalability, and DA.</li>
|
||
<li>Web3 developers wanting to create applications on cynical rollups secured by JAM.</li>
|
||
<li>DOT Holders aiming to increase CoreTime demand.</li>
|
||
</ol>
|
||
<h1 id="jam-service-design"><a class="header" href="#jam-service-design">JAM Service Design</a></h1>
|
||
<h2 id="overview"><a class="header" href="#overview">Overview</a></h2>
|
||
<p>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 here; validating the state trie root alone is sufficient for securing rollups.</p>
|
||
<p>This JAM Service strategy, as hinted in the JAM Gray Paper, aggregates storage proofs of altered smart account/contract states into a chain of work packages. These validate an uninterrupted chain of an optimistic rollup's blocks against the state root ${\bf H}_r$.</p>
|
||
<p>Instead of relying on a <em>promise</em> that the state root is correct unless proven otherwise, JAM validates it using storage proofs for each contract update across $N$ blocks.</p>
|
||
<p>The rollup operator submits headers and Merkle proofs in a chain of work packages $..., p_{n-1}, p_{n}, p_{n+1}, ...$ corresponding to the rollup chain, grouping $N$ blocks of data in each package. Typically, each work package $p_n$ requires a prerequisite work package $p_{n-1}$.</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>In JAM's refine 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 blocks $i$ through $j$</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>Imported Data Segment</em> ${\bf i}$</td><td>Last ${\bf H}$ validated by the service in the <em>previous</em> work package $p_{n-1}$</td></tr>
|
||
<tr><td><em>Extrinsics</em> $\bar{{\bf x}}$</td><td>Header ${\bf H}$, block hash $H({\bf B})$, and Merkle proofs $\Pi$ detailed below</td></tr>
|
||
<tr><td><em>Work Items</em> ${\bf w} \in \mathbb{I}$</td><td>Summary of the first and last blocks ($i$ to $j$)</td></tr>
|
||
<tr><td><em>Exported Data Segment</em> ${\bf e}$</td><td>Last validated ${\bf H}$, used in the <em>next</em> work package $p_{n+1}$</td></tr>
|
||
<tr><td><em>Work Result</em> ${\bf r}$</td><td>$N$ header hashes $H({\bf H})$ and $N$ block hashes $H({\bf B})$</td></tr>
|
||
</tbody></table>
|
||
</div>
|
||
<p>Refine's operations:</p>
|
||
<ol>
|
||
<li>Check for authorization ${\bf o}$.</li>
|
||
<li>Perform <code>historical_lookup</code> to fetch the last on-chain state in the anchor block.</li>
|
||
<li><code>Import</code> the last header ${\bf H}$ and confirm that the imported data segment ${\bf i}$ matches the <code>historical_lookup</code>.</li>
|
||
<li>For each extrinsic header in ${\bf H}$:
|
||
<ul>
|
||
<li>Ensure that each header forms a chain, with ${\bf H}_p$ matching the previous extrinsic $H({\bf H})$, except for the first header, which must match the previous 2.</li>
|
||
<li>Using the state root ${\bf H}_r$, validate all Merkle proofs.</li>
|
||
</ul>
|
||
</li>
|
||
<li><code>Export</code> the header of the last extrinsic successfully validated.</li>
|
||
<li>Output the work result, up to $2(j-i+1)$ hashes: two hashes per extrinsic, $H({\bf H})$ and $H({\bf B})$.</li>
|
||
</ol>
|
||
<p>The refine process uses 3 host functions, with the main computation focused on Merkle proof validation.</p>
|
||
<p>As detailed in GP, work results in guaranteed work reports are assured, audited, and judged following the ELVES protocol. JAM finalizes its audited blocks via GRANDPA voting, ensuring the rollup’s state can be trusted for subsequent operations.</p>
|
||
<h3 id="key-validation-process-storage-proofs"><a class="header" href="#key-validation-process-storage-proofs">Key Validation Process: Storage Proofs</a></h3>
|
||
<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 an overview. The state root ${\bf H}_r$ is a cryptographic commitment to the entire rollup state at that block height. Notably, validation does not calculate the state root ${\bf H_r}$ based on block <em>transactions</em>, which would necessitate the entire state of the rollup. Instead, storage proofs (or "witness data") enable the ORU to prove that specific storage values exist within a particular state root. Only the last witness per contract address is needed in a work package of $N$ blocks.</p>
|
||
<p>The central assumption is that if the work package proves all account/contract storage items over $N$ of blocks, which are guaranteed/assured/audited by a subset of JAM validators, then the sequence of state transitions in these blocks is valid.</p>
|
||
<p>This chaining of state roots ensures continuity and trust in the rollup secured by this JAM Service:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Each block’s state root can be verified against the previous state, allowing nodes to validate state changes trustlessly.</p>
|
||
</li>
|
||
<li>
|
||
<p>Inclusion in Parent Block Hash: Since each block header ${\bf H}$ includes the previous header hash ${\bf H}_p$ and indirectly references the previous state root ${\bf H}_r$, each block and header also serves as a cryptographic reference to the prior state.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The core operation verifies proofs against the state root, enabling efficient, trustless block sequence validation based solely on headers, which are much smaller than full transaction blocks.</p>
|
||
<p>For now, we consider <em>100%</em> of storage keys and values output by the trace of a block. A more sophisticated approach to sample the set of storage keys based on JAM's public entropy $\eta_3$ may be warranted to limit work packages to within JAM's limits, made available through <code>historical_lookup</code> operations.</p>
|
||
<h2 id="accumulate"><a class="header" href="#accumulate">Accumulate</a></h2>
|
||
<p>The <code>accumulate</code> process ensures that all rollup data necessary to validate the rollup is available in JAM DA. Accumulate is an entirely synchronous <em>on-chain</em> operation performed by all JAM Validators (rather than <em>in-core</em> as with Refine). Computation is carried out first by the JAM Block Author and the newly authored block sent to all Validators.</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>The service maintains a summary of fully validated blocks of each chain in 3 service storage keys:</p>
|
||
<ul>
|
||
<li>the first block number $a$ validated with data fully available</li>
|
||
<li>the last block number $b$ validated with data fully available</li>
|
||
<li>a window parameter $w$, modeling the maximum $b-a$</li>
|
||
</ul>
|
||
<p>For every block number in this range, the block number has its own key to store the header hash and the block hash.</p>
|
||
<p>The function of this data storage represents <strong>both</strong> of the following:</p>
|
||
<ul>
|
||
<li>the refine validation has been completed <strong>and</strong></li>
|
||
<li>the block and header preimages are available in JAM's DA</li>
|
||
</ul>
|
||
<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>Wrangled Work Results</em></td><td>Chain ID (e.g., 10, 42161, etc.), block number start $i$ and end $j$ followed by pairs of $H({\bf H})$ and $H({\bf B})$</td></tr>
|
||
</tbody></table>
|
||
</div>
|
||
<ol>
|
||
<li><code>read</code> fetch $a, b, w$ based on Chain ID. Validate that $i=b+1$.</li>
|
||
<li><code>solicit</code> is called for both hashes in the wrangled work results.</li>
|
||
<li>Advance $b$ by 1 if:</li>
|
||
</ol>
|
||
<ul>
|
||
<li>both ${\bf a}_l(H({\bf B}))$ and ${\bf a}_l(H({\bf H}))$ are "available"</li>
|
||
<li>the header ${\bf H}$ is contained with ${\bf B}$</li>
|
||
</ul>
|
||
<ol start="5">
|
||
<li>If $b-a$ exceeds the window $w$, advance $a$ by 1 if both ${\bf a}_l(H({\bf B}))$ and ${\bf a}_l(H({\bf H}))$ are "forget".</li>
|
||
<li><code>write</code> $a$ and $b$ back to storage.</li>
|
||
</ol>
|
||
<p>Necessarily, the ORU operator must provide both preimages for the chain to be considered valid. If any block or header is not made available by the ORU operator, $b$ will not advance.</p>
|
||
<p>Under normal operations, the above process will result in a full set of blocks and header preimages being in JAM's DA layer.</p>
|
||
<p>Moreover, the <code>forget</code> operation ensures that storage is bounded by $w$.</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 JAM Testnet by JAM implementers. A Keccak256 host function is used for expedience, and the preimage hash function will be adjusted to this for PoC.</p>
|
||
<p>Real-world work packages can be developed for OP Stack chains like Base and Optimism (currently with 30 blocks/minute) and Arbitrum, which operates at 150 blocks/minute. The results of "trace_block" JSON-RPC calls enable 3 x 1440 work packages per day for these top 3 ETH rollups. This is ample for PoC.</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 Polkadot and non-Polkadot rollup services will provide valuable data for determining these parameters.</p>
|
||
<p>The gas required for <code>refine</code> is proportional to the number of storage proofs submitted in a work package and the average size of each proof. To upper-bound storage proofs, sampling using an entropy state variable $\eta_3$ may be necessary, although accessing it remains unclear.</p>
|
||
<p>The gas required for <code>accumulate</code> is proportional to the number of solicit and forget operations. It is believed that accumulate's gas cost is nominal and poses no significant issue. However, the storage rent model common to all blockchain storage applies to the preimage, which is explicitly tallied. Fortunately, this is upper-bounded by $w$.</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.</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 attention 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>The proposal introduces no new privacy concerns.</p>
|
||
<p>Raw PVM assembly may be preferred in a production implementation, along with a host function for Keccak256 to minimize issues related to compiler bugs.</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>Solutions to model other elements in the state trie (account balances and nonces) are not covered in this service design yet.</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.</p>
|
||
<p>An interoperable JAM messaging service between both kinds of non-Polkadot rollups and Polkadot rollups would be highly desirable.</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>
|
||
<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. None of these alternatives provide the same UX enhancement enabled by "cynical" rollups.</p>
|
||
|
||
</main>
|
||
|
||
<nav class="nav-wrapper" aria-label="Page navigation">
|
||
<!-- Mobile navigation buttons -->
|
||
<a rel="prev" href="../new/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="../proposed/0102-offchain-parachain-runtime-upgrades.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="../new/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="../proposed/0102-offchain-parachain-runtime-upgrades.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>
|