Foundation Mission Request – Remote Static Call Proof of Concept

To take on this project, submit a proposal to this thread by xxx. Read more about Missions here.

S4 Intent: Progress Towards Technical Decentralization
Proposal Tier: Ember
Baseline grant amount: 15k OP
Accepting one or multiple proposals: Multiple
OP Labs or Optimism Foundation Sponsor: Mark (@tynes)
Submit by: July 18, 2023 at 19:00 GMT
Selection by: July 28, 2023 at 19:00 GMT

How will this Foundation Mission (RFP) help accomplish the above Intent?

A decentralized future is one where there are many L2 rollup chains. In order to support many L2 chains without introducing too much fragmentation it is critical that there is shared state between them. This RFP introduces a new REMOTESTATICCALL primitive which allows L2 nodes to query L1 state statically using the existing STATICCALL RPC. This greatly improves the flexibility of querying the shared state between chains.

This can be used for novel use-cases such as:

Cross-chain wallet management — see Vitalik’s recent post
Oracle update reading — read oracle values on L1
EVM-based indexers — when combined with custom attributes in the derivation function, this enables more generalized L1 state inspection for provable EVM-based indexers.

Tons of use cases become possible!

What is required to execute this Foundation Mission (RFP)?

Success criteria:

A fork of Optimism where the local devnet includes all of the changes required for the REMOTESTATICCALL functionality.
A test suite which can be run against the local devnet which deploys contracts that use the REMOTESTATICCALL functionality and show it is working.
This includes:
- Simple gas metering of the REMOTESTATICCALL
- Bonus: Analysis or recommendations for what the gas metering should be if deployed to production

Recommended solution:

Implement a precompile in op-geth which makes a STATICCALL RPC request to the L1 Geth. The gas is proportional to the gas allocated to the CALL of the precompile. The STATICCALL made to L1 Geth uses the latest L1 blockhash stored in the L2 L1Block predeploy.
Archive node of L1 Geth so the STATICCALL can be made on historical blocks.
- Bonus: Avoid needing an archive node.

How should the Foundation measure progress towards this Mission (RFP)?

Progress can be measured based upon the completion of the following milestones:

Specification: A specification for how the REMOTESTATICCALL would be implemented. This includes the interface to the precompile and its gas consumption.
Geth PoC: A single commit to op-geth which adds the functionality and unit tests.
Executable devnet demo: An easy to run test suite against the standard Optimism devnet which demonstrates the functionality.

How should badgeholders measure impact upon completion of this Mission (RFP)?

Number of developers who understand this new primitive
- Fewer lines of code is better
- More documentation is better
Number of developers who want this new primitive
Number of developers building on top of this new primitive

Application instructions

To apply for this RFP, please complete the form in the expandable section below and leave your response as a comment on this issue thread. Submissions will be open until July 18, at which time the Foundation will review all submissions and select individual/team(s) to complete the work defined here.

Submission form

Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation may reach out using the contact info provided to request more information as necessary.

Foundation Mission (RFP) Application

Please verify that you meet the qualifications for submitting at the above Tier

Alliance Lead: Please specify the best point of contact for your team
Contact info:
L2 recipient address:
Please list the members of your Alliance and link to any previous work:

Read more about Alliances here

What makes your Alliance best-suited to execute this Mission?

[...]
[...]

Please describe your proposed solution based on the above Solution Criteria (if applicable):

[...]
[...]

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

[...]
[...]

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

[...]
[...]

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

[...]
[...]

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

[...]

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[ ] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[ ] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[ ] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[ ] I confirm that I have read and understand the grant policies
[ ] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

Jun 19 '23 23:06 bdresser

Foundation Mission (RFP) Application Please verify that you meet the qualifications for submitting at the above Tier

Alliance Lead: me. Contact info: @libcso6 L2 recipient address: 0x502FcE03Af4bFD3dc991A6f7d0523cB920E1DBC8 Please list the members of your Alliance and link to any previous work:

Kelvyne (storage proof verifier precompile in op-geth] and starknet storage proof verifier in Solidity

What makes your Alliance best-suited to execute this Mission?

I have a good understanding of how op-geth works. I strongly think this feature is very powerful and enables a lot of cool features.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

I propose to implement a new opcode that will query a L1 node to execute a call. (I would also think about adding REMOTEGETBALANCE, REMOTEGETCODE, etc, based on the state trie). These opcodes would use the L1Block predeploy contract to know at which block the call should be done. Account information could be checked against the state root. I don't see an obvious way to check correctness of a call (we assume that the node behaves correctly). A solution like helios could also be interesting to validate that the information of the L1 are valid.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

A L2 contract must be able to read contract and accounts of L1.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

None

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

Jun 21 '23 13:06 Kelvyne

Alliance Lead: Uma Roy Contact info: [email protected] L2 recipient address: 0x54E05bDBa158a1DCda0420bc803D35c2FAf6655E Please list the members of your Alliance and link to any previous work: Uma Roy (Github, Twitter)

Previous Work:

Cross chain messaging system with ZK light client security:
- Contracts: https://github.com/succinctlabs/telepathy-contracts
- Circuits: https://github.com/succinctlabs/telepathy-circuits
- Docs: https://docs.telepathy.xyz/
- Explorer: https://explorer.telepathy.xyz/
- Used in production by Gnosis to secure their Omnibridge: https://blog.succinct.xyz/blog/omnibridge
Design of new shared sequencer architecture enabling better rollup interoperability: shared validity sequencing
- https://www.umbraresearch.xyz/writings/shared-validity-sequencing
State Query protocol to allow contracts on any chain to query state on any other chain: https://docs.telepathy.xyz/state-queries/getting-started
Foundry Eth RPC cheatcode: https://github.com/foundry-rs/foundry/pull/5297

What makes your Alliance best-suited to execute this Mission?

Our alliance works on Succinct Labs (https://succinct.xyz/), a company dedicated to more secure blockchain interoperability. Our first protocol, Telepathy, is a cross-chain messaging protocol backed by zkSNARK-enabled light clients to allow for more secure cross-chain interoperability.

More recently, we have been working on a new protocol called Succinct State Queries that solves for the same problem as this RFP: allow users on any chain to read view functions/data from another other chain. As can be seen from the state query docs, the protocol allows for developers to request a view function call on any other chain and have that result availble to them in their smart contract.

From implementing our State Query protocol, we have thought a lot about the best UI/UX for developers to request state queries from other chains. We also have a very good understanding of geth, EVM and Solidity that will be useful for implementing this RFP.

We think state queries are super powerful and unlock a lot of functionality for cross-chain data interoperability. We think eventually having state queries in-protocol will unlock interesting cross-chain interactions for the OP stack, and we want to contribute towards making it happen!

Please describe your proposed solution based on the above Solution Criteria (if applicable):

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

Note: Timeline estimates are given in weeks, assuming work starts after July 28th RFP selection date.

We would implement a precompile in op-geth (precompile is more appropriate than opcode or predeploy since predeploys are restricted to existing Solidity logic) that can be called with IRemoteStaticCall(precompile_addr).eth_call(from, to, data) and would return a bytes result. (2 weeks for this bullet & all related bullet points below)
- The precompiled contract interface that we would need to implement can be found here
The gas for the above eth_call would be metered with a appropriately set constant
The precompiled contract would use the latest L1 blockhash stored in the L1Block predeploy contract and use the eth_call RPC method to call an L1 archival node. The result would be returned as bytes memory.
- The archival node would be called with:

{
  "method": "eth_call",
  "params": [
    {
      "from": from,
      "to": to,
      "data": data
    },
    L1Block.number()
  ],
  "id": 1,
  "jsonrpc": "2.0"
}

We would run a local Optimism devnet with the above changes & create an example test suite of contracts that use REMOTESTATICCALL to show off the new precompile's functionality. (2 weeks to create devnet + contract test suite)
We would analyze several options of more advanced gas metering and include a short design doc on this analysis & recommendations for gas metering in production. (1 week, in parallel with below)
- Precompile contracts can only use the input to the function call to determine how much gas is required
We would also create a design doc with recommendations for how to add similar precompiles for other RPC methods that can be useful in the context of L2 reading L1 state, including eth_getStorageAt, eth_getBalance, eth_getCode, eth_getTransactionByHash, including brainstorming how to add this functionality in the most generic way possible. (1 week, in parallel to above design doc)

Timeline: In total we anticipate that this RFP will take 4-5 weeks to complete all of the above items.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Whether there is an Optimism devnet with REMOTESTATICCALL functionality and a contract suite that uses this functionality and demonstrates how it can be used.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

None.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Upfront capital is not a barrier.

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies I understand that I will be expected to following the public grant reporting requirements outlined here

Jul 14 '23 20:07 puma314

Everyone is qualified for Ember tier

Alliance Lead: Chomtana Chanjaraswichai Contact info: [email protected] L2 recipient address: 0x5F4BCCcb5C2CBB01c619F5CFED555466e31679b6 Please list the members of your Alliance and link to any previous work:

Chomtana Chanjaraswichai

Related to geth (Explanation in the next section)

https://github.com/Chomtana/kdi-chain-geth
https://github.com/Chomtana/kdi-chain-setup

Other experiences

Solo developer developing Opti.Domains 2
1st in Axelar 2nd Code4rena audit contest 2
2nd in Axelar 1st Code4rena audit contest 2
Contribute to Seaport in Gas Optimization 2
Fork Wagmi Library to integrate support for custom ENS UniversalResolver support 2
Fork Rainbowkit Library to integrate support for the domain name on Optimism 1
Participated in SCB Bangkok Blockathon 2023 and won 3rd price with 838.Earth project 1
Participated in SCB Bangkok Blockathon 2021 and won 2nd price with Estate-Onblock project 1
Won silver medal in 13th Thailand Olympiad in Informatics (TOI13)
Won many hackathons in the past

What makes your Alliance best-suited to execute this Mission?

I have experienced patching BAS geth implementation. Although they advertise BAS as perfect, it still has some hidden problems. Mainly because they use an ancient version of geth.

That version of geth doesn't support gpo.ignorePrice flag, so I implement it.

I have also implemented custom predeploy (KDITokenContract, KDIMasterChefContract)

https://github.com/Chomtana/kdi-chain-geth

After that, I modified deployment docker to allow deploying multiple parts to different machines

https://github.com/Chomtana/kdi-chain-setup

Please describe your proposed solution based on the above Solution Criteria (if applicable):

My solution is similar to the one above. The differences are in gas estimation to prevent DDoS and precompile interface.

I propose to implement precompiles that require a block number to be explicitly passed into every precompiles.

Precompiles will support this interface (Subject to change)

https://github.com/Chomtana/opstack-remotestaticcall-sdk/blob/main/contracts/IRemoteCallPrecompile.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IRemoteCallPrecompile {
    function eth_call(
        uint256 blockNumber,
        address from,
        address to,
        uint256 value,
        bytes calldata data
    ) external view returns (bytes memory);

    function eth_getBalance(
        uint256 blockNumber,
        address target
    ) external view returns (uint256);

    function eth_getStorageAt(
        uint256 blockNumber,
        address target,
        uint256 position
    ) external view returns (bytes32);

    function eth_getCode(
        uint256 blockNumber,
        address target
    ) external view returns (bytes memory);

    function eth_codeSize(
        uint256 blockNumber,
        address target
    ) external view returns (uint256);
}

Note that each precompile has its own address and are implemented to ignore function selector just to keep compatibility with solidity compiler.

On precompile execution, it will send two RPC requests to a local L1 archive node (Remote node is not feasible due to latency)

First, it will estimate gas with a hard limit of 1M gas to prevent DDOS with an infinite loop that can delay an entire network

{
	"jsonrpc":"2.0",
	"method":"eth_estimateGas",
	"params":[{
          "from": "...",
          "to": "...",
          "value": "...",
          "data": "...",
          "gas": "0xF4240"
        }, "..."],
	"id":1
}

If gas estimation is failed -> return a very largeeee value as gas to have it revert with gas limit exceeded. (Developers are responsible to make sure it doesn't revert or pass a manual gas limit to prevent it from consuming all gas)

Then it will perform eth_call

{
	"jsonrpc":"2.0",
	"method":"eth_call",
	"params":[{
		"from": "...",
		"to": "...",
		"gas": "0xF4240",
		"value": "...",
		"data": "..."
	}, "..."],
	"id":1
}

For other basic instruction like eth_getBalance, we don't need to do gas estimation, just use a hardcoded value of approximately 50000 gas explained below

Then I will implement a solidity library that allow developer to easily query latest L1 data by having that library query latest L1 block from L1Block.number() and pass it into our precompiles.

https://github.com/Chomtana/opstack-remotestaticcall-sdk/blob/main/contracts/RemoteCall.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "./IRemoteCallPrecompile.sol";

address constant _REMOTE_STATIC_CALL_PRECOMPILE = address(
    0x0000000000000000000000000000000000009000
);
address constant _REMOTE_GET_BALANCE_PRECOMPILE = address(
    0x0000000000000000000000000000000000009001
);
address constant _REMOTE_GET_STORAGE_AT_PRECOMPILE = address(
    0x0000000000000000000000000000000000009002
);
address constant _REMOTE_GET_CODE_PRECOMPILE = address(
    0x0000000000000000000000000000000000009003
);
address constant _REMOTE_CODE_SIZE_PRECOMPILE = address(
    0x0000000000000000000000000000000000009004
);

interface IL1BlockNumber {
    function number() external view returns(uint64);
}

IL1BlockNumber constant _REMOTE_L1_BLOCK = IL1BlockNumber(0x4200000000000000000000000000000000000015);

library RemoteCall {
    // ===================================================
    // Historical block query
    // ===================================================

    function remoteStaticCall(
        uint256 blockNumber,
        address from,
        address to,
        uint256 value,
        bytes calldata data
    ) public view returns (bytes memory result) {
        return
            IRemoteCallPrecompile(_REMOTE_STATIC_CALL_PRECOMPILE).eth_call(
                blockNumber,
                from,
                to,
                value,
                data
            );
    }

    function remoteGetBalance(
        uint256 blockNumber,
        address target
    ) public view returns (uint256) {
        return
            IRemoteCallPrecompile(_REMOTE_GET_BALANCE_PRECOMPILE)
                .eth_getBalance(blockNumber, target);
    }

    function remoteGetStorageAt(
        uint256 blockNumber,
        address target,
        uint256 position
    ) public view returns (bytes32) {
        return
            IRemoteCallPrecompile(_REMOTE_GET_STORAGE_AT_PRECOMPILE)
                .eth_getStorageAt(blockNumber, target, position);
    }

    function remoteGetCode(
        uint256 blockNumber,
        address target
    ) public view returns (bytes memory) {
        return
            IRemoteCallPrecompile(_REMOTE_GET_CODE_PRECOMPILE).eth_getCode(
                blockNumber,
                target
            );
    }

    function remoteCodeSize(
        uint256 blockNumber,
        address target
    ) public view returns (uint256) {
        return
            IRemoteCallPrecompile(_REMOTE_CODE_SIZE_PRECOMPILE).eth_codeSize(
                blockNumber,
                target
            );
    }

    // ===================================================
    // Latest block query
    // ===================================================

    function remoteStaticCall(
        address from,
        address to,
        uint256 value,
        bytes calldata data
    ) public view returns (bytes memory result) {
        return remoteStaticCall(_REMOTE_L1_BLOCK.number(), from, to, value, data);
    }

    function remoteGetBalance(
        address target
    ) public view returns (uint256) {
        return remoteGetBalance(_REMOTE_L1_BLOCK.number(), target);
    }

    function remoteGetStorageAt(
        address target,
        uint256 position
    ) public view returns (bytes32) {
        return remoteGetStorageAt(_REMOTE_L1_BLOCK.number(), target, position);
    }

    function remoteGetCode(
        address target
    ) public view returns (bytes memory) {
        return remoteGetCode(_REMOTE_L1_BLOCK.number(), target);
    }

    function remoteCodeSize(
        address target
    ) public view returns (uint256) {
        return remoteCodeSize(_REMOTE_L1_BLOCK.number(), target);
    }
}

Our experiment with gas estimation test from simple to complex operations

Basic mapping read -> 0x5dcd: 24013 gas
Opti.domains getReverseUniversalResolver -> 0x9bdd: 39901 gas
Opti.domains universal resolver reverse resolve address -> 0x1baa2: 113314 gas

Since "Opti.domains universal resolver reverse resolve address" operation is a super complex one and it uses a little more than 100k gas so we can use 100k gas as a soft limit and 1M gas as a hard limit.

Given gas limit is 30M/block, block time = 2s and latency for basic mapping read = 4ms. We can perform 300 basic mapping read per block, or 100k gas per remote static call. 100k gas is approximately 24013 * 4 = 96052.

So, we found an optimal gas metering equation of (L1 gas usage) * 4

Basic operations shouldn't has a latency of more than 2ms, so 50000 gas is approximate

Note: If I or other find a more optimal gas constants, I can adopt to that

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

Implement precompiles mentioned above (2 weeks)
Implement solidity libraries mentioned above (1 week)
Implement test cases (2 weeks)
Deploy OP Stack devnet with above features (0.5 week)
Implement DDOS and load testing (0.5 week)
Public design documents and developer documents (1 weeks)

Approximately 7 weeks to complete

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Precompiles and solidity libraries implemented properly and passed test cases
Published design documents and developer documents

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

None

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

No

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

Jul 17 '23 04:07 Chomtana

Foundation Mission (RFP) Application

Alliance Lead: George Spasov
Contact info: [email protected]
L2 recipient address: 0x6eDf76FD16Bb290A544fDc14fBB4b403D1DEeD9f
Please list the members of your Alliance and link to any previous work:
- George Spasov, co-founder of LimeChain. Most recently built Extractoor - Library of contracts used for proving the Merkle Patricia Tree (MPT) inclusion of certain storage inside an OP-stack based rollup. Co-author of EIP-4400 2, Co-founder of EnterDAO and contributions to many other projects.
- Daniel Ivanov, Senior Blockchain Architect and R&D at LimeChain. Most recently worked on Wisp - cross-rollup communication protocol using ZK proofs (deprecated) and led the research on proving rollups state 1. Co-author of EIP-4400, Co-founder of EnterDAO and contributions to many other projects.
- Zhivko Todorov - R&D at LimeChain. Leading governance and ecosystem efforts. Co-founder of EnterDAO.

What makes your Alliance best-suited to execute this Mission?

LimeChain is a blockchain development company building blockchain infrastructure and apps since 2017, having worked with companies and organizations such as The Graph, Ledger, Celo, Polkadot, Coinbase and Tally among others.

L1Block contributors - We just got awarded our first OP grant - through a Mission Proposal and are currently working on Extending the L1Block predeploy contract.
op-geth knowledge - we have good understanding of op-geth and the wider OP stack due to our previous and current client work.
Good understanding of cross-rollup messaging and cross rollup use cases - Have done PoC of cross-rollup communication for OP↔Base. Heavily studied tha UX needs of developers for their cross-rollup and cross-chain needs
Worked on the L2 view of OP from L1 - Have contributed the open-source library “extractoor” that helps reason about the state of OP from L1 and other L2s.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

We will implement a new precompile REMOTESTATICCALL as prescribed by the RFP - the precompile will execute a remote eth_call to the L1 node against the latest block number exposed by the L1Block contract (by default) or against a specific block number passed as an argument to the precompile. It will be a precompile at an address with sufficient offset from the canonical EVM precompiles. Exposing the interface as a precompile instead of OPCODE will lead to a better developer experience and will negate the need for bothering with the compilers.
We will enable REMOTESTATICCALL to work not only with the latest block from the L1, but also with any of the historical block hashes that are saved in the L1Block once “Extend the L1Block contract to store historical block hash data" is delivered
We will do an analysis of the impact of the precompile in terms of the node’s performance degradation and stability. Load testing will be performed using Flood to assess the impact of the precompile on the node’s performance in the case of
- Short / Long calldata (f.e usage of multicall)
- Short / Long execution of eth_call (high gas limit)
- Low / High L1 node latency
Based on the findings of the impact analysis we will propose:
- Structure and values for the gas cost of the REMOTESTATICCALL. The gas cost must have several components in order to best resemble the consumed resources and ensure the stability of the network. A rough idea of gas cost components includes:
  - Static gas for calling the precompile
  - Dynamic gas for the data word size (calldata) causing memory expansion
  - Static gas for executing an RPC call
  - Dynamic gas for the L1 gas consumed by the execution of eth_call
  - Dynamic gas for the data word size (result) causing memory expansion
- Restrictions of the precompile such as calldata size, the L1 gas limit for eth_call
- Suggestion on a maximum latency to the L1 nodes

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

We will provide specifications of the interface of the precompile and its execution constraints. We will provide the solidity interface that can be used for triggering the precompile from a smart contract. The reasoning will be showcased in the repository and in the OP governance forum for feedback. Timeline: up to 1 weeks from mission start
We will create a fork of op-geth and add the precompile We will provide Solidity contracts to test the precompile. These will act as Proof-of-Concept. Timeline: up to 2 weeks from the previous step - 3 weeks from mission start.
We will ensure it is behaving as expected via the test suite in the node. Timeline: up to 3 weeks from the previous step - 6 weeks from mission start.
We will analyse and propose a sensible gas cost for the precompile. The reasoning will be showcased in the repository and in the OP governance forum for feedback. Timeline: up to 3 week from the previous step - 9 weeks from the mission start.
We will provide an easy executable devnet demo. We will provide documentation on the usage of the precompile. Timeline: up to 1 week from the previous step - 10 weeks from the mission start.

Total timeline: up to 10 weeks from the mission start.

Please define the critical milestone(s) that should be used to determine whether you’ve executed this proposal:

All the milestones will be hit in public in an open-source GitHub repository.

Creation of specification and forum post.
Modification of op-geth and testing it through unit tests and Solidity
Gas metering analysis and public proposal.
Providing executable devnet demo.
Documentation of the usage.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

None

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

Jul 17 '23 11:07 Perseverance

Foundation Mission (RFP) Application

Alliance Lead: Yi Sun
Contact info: [email protected]
L2 recipient address:
Please list the members of your Alliance and link to any previous work:
- Yi Sun (Github, Twitter), Founder of Axiom, Professor at UChicago Statistics (on-leave), MIT Math PhD, Harvard Math BA.
- Jonathan Wang (Github, Twitter), Founder of Axiom, Former MIT Math Instructor, UChicago Math PhD, Harvard Math BA.
- Yu Jiang Tham (Github, Twitter), Lead creator of Axiom SDK and Axiom Explorer.

Previous Work:

Trustless on-chain historical L1 state reads with ZK:
- Mainnet+Goerli demo: https://demo.axiom.xyz/token-price-v3
- Blog: https://www.axiom.xyz/blog
- Docs: https://docs.axiom.xyz/
- Contracts: https://github.com/axiom-crypto/axiom-v1-contracts
- ZK Circuits: https://github.com/axiom-crypto/axiom-eth
The first ZK implementation of ecpairing
- https://github.com/yi-sun/circom-pairing
Trustless Uniswap oracle with ZK:
- https://www.axiom.xyz/blog/uniswap

What makes your Alliance best-suited to execute this Mission?

Axiom is the first ZK coprocessor scaling data-rich applications on Ethereum. Prior to Axiom there was no simple way for smart contracts to trustlessly access historic on-chain data. Now developers can use Axiom to make async on-chain calls for all L1 state. Axiom introduces a new way to access data and compute on-chain based on cryptography. All results returned by Axiom are verified on-chain by zero-knowledge proofs, meaning smart contracts can use them without additional trust assumptions.

We are hyper-focused on empowering developers to build without limits. This means allowing them to access data in the most user-friendly and secure way possible.

We are extremely excited about the possibilities that will be unlocked by this REMOTESTATICCALL primitive. Furthermore we want to help build this primitive in a way that maintains existing L2 security guarantees.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

We propose to follow the recommended solution, with an addendum to fully integrate the new REMOTESTATICCALL as a new opcode.

Implement the REMOTESTATICCALL precompile in op-geth. For best latency, this will make a STATICCALL to a local L1 Geth client.
- Gas will be proportional to the gas allocated to the CALL, plus a constant factor to account for the latency of calling the L1 client. We will perform comprehensive benchmarking across opcodes to determine the correct proportions.
Implement a HISTORICREMOTESTATICCALL precompile in op-geth that allows the user to supply the output of a STATICCALL on a historical block as calldata.
- This removes the need for a local archive node of L1 Geth, as the user makes the STATICCALL to an archive node off-chain before executing the precompile.
Implement a fault proof contract for both precompiles.
- The fault proof concept is the same for both: the issue is that at the time of challenge, the L2 may no longer have record of the previous L1 blockhash. However, the challenger can use Axiom to ZK verify all SLOADs performed in the CALL, and use the L1->L2 message passing bridge to send this data to L2. Now the rest of the CALL can be integrated into existing fault proof VMs like Cannon.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

Timeline estimates assume that work starts after RFP selection and approval date.

Implement REMOTESTATICCALL and HISTORICREMOTESTATICCALL precompiles in op-geth, with sample smart contract integration. (1 week)
Latency and performance profiling to determine gas metering constants (1 week)
Deploy OP Stack devnet with test suite of contracts (1 week)
Implement and deploy smart contracts using Axiom the validate historic state reads in REMOTESTATICCALL calls (1 week)
PR demonstrating integration of fault proofs for new precompiles into Cannon (1 week)

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Precompiles deployed on devnet with example contracts
Open-source all code with both technical design specs and explainer blog posts
Working integration of fault proofs with Axiom

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

None

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Not a barrier

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

Jul 18 '23 14:07 yi-sun

Submissions for this RFP are now closed. Thanks to everyone who submitted a proposal!

Someone from the Optimism Foundation will reach out on or shortly after July 28 to communicate which proposal(s) have been accepted and schedule a kickoff. We may also reach out individually using the contact info you've provided if we want to discuss your proposal in more detail.

In the meantime, feel free to tag me here or reach out directly ([email protected]) with any questions.

Jul 18 '23 22:07 bdresser

Hello! Thank you again to every team who submitted a proposal.

We're happy to share we'll be moving forward with the proposal from @puma314 and Succinct Labs. Their history of shipping and quality research along with their proposal make them a solid fit for the project.

@puma314 we will be in touch directly to discuss the project and expectations in more detail.

For all other teams here: we'd love to help you find the right way to contribute to the Optimism Collective. See the rest of the issues in the Ecosystem Contributions repo for ideas, suggestions, and other possible projects. And stay tuned for more RFPs posted in the next few months. Thank you again for your proposals.

Jul 25 '23 21:07 bdresser

Hi All,

Just wanted to express our emphatic support for this functionality!

We are working on an onchain token metadata service (https://tkn.xyz), and it would be amazing if developers could consume this data from anywhere in the superchain. Token data, including L2 contract addresses, are hosted on ENS on Eth Mainnet.

Here is the $WBTC dataset for reference: https://app.ens.domains/wbtc.tkn.eth.

Aug 06 '23 19:08 technicallykind

Progress can be tracked here: https://github.com/ethereum-optimism/op-geth/pull/114

The geth implementation is in a good place and ready to be tested end to end. We would like to have a poc repo that anybody can try running the patched op-geth against to show off the functionality soon

Aug 22 '23 16:08 tynes

As a progress update, I implemented a patch to op-geth to implement this precompile and also a patch to the optimism monorepo to get the devnet working with the patch op-geth. An example POC repo that uses this precompile (and a library that makes it easy to interact with the precompile) can be found here: https://github.com/succinctlabs/op-stack-remote-static-call. It also includes documentation of the development of this precompile which hopefully can be a helpful guide to future contributors to the Op Stack.

The patches can be found at these PRs:

op-geth patch: https://github.com/ethereum-optimism/op-geth/pull/114
optimism monorepo patch: https://github.com/ethereum-optimism/optimism/pull/7147

There is 1 remaining blocker to getting this POC fully working on the devnet, as the devnet L1Block predeploy does not track the provided archive node RPC that the remote static call is using, leading to a mismatch in the devnet L1 block number (which the precompile uses).

Sep 09 '23 21:09 puma314

Whats happening with this? Is this gonna go into an upgrade or just proof of concept @puma314 @tynes

Jan 04 '24 22:01 aodhgan

@opjulian can you summarize the state of this concept? I'm having trouble understanding if/when it might be something that could go into production, but in general, I think that being able to read L1 data from a rollup would add many use-cases!

Jun 18 '24 21:06 ryley-o

Hi @ryley-o,

Best to direct those questions to the OP Sponsor (@tynes) or the selected team (@puma314)

Thanks!

Jun 19 '24 00:06 opjulian

This is Suvi from Mimir Wallet. When will this be merged into op-stack? We have some cool stuff to build on top of this.

Jul 09 '24 11:07 dejavukong

@tynes is this the appropriate PR to track progress on? https://github.com/ethereum-optimism/op-geth/pull/114

Jul 17 '24 11:07 stevennevins

ecosystem-contributions
ecosystem-contributions copied to clipboard