Foundation Mission Request: Remote Static Call Proof of Concept #76
Comments
bdresser
added
Intent: Technical Decentralization
Foundation Mission Request
|
Foundation Mission (RFP) Application Alliance Lead: me.
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):
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:
|
|
Alliance Lead: Uma Roy Previous Work:
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 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.
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:
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:
|
|
Everyone is qualified for Ember tier Alliance Lead: Chomtana Chanjaraswichai Chomtana Chanjaraswichai Related to geth (Explanation in the next section)
Other experiences
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) // 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 {
"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 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
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 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:
Approximately 7 weeks to complete 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.):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:
|
Foundation Mission (RFP) Application
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.
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 piece of work:
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.
Please list any additional support your team would require to execute this mission (financial, technical, etc.):
Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:
|
Foundation Mission (RFP) Application
Previous Work:
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.
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.
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.): 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:
|
|
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. |
|
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. |
|
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. |
|
Progress can be tracked here: ethereum-optimism/op-geth#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 |
|
As a progress update, I implemented a patch to The patches can be found at these PRs:
There is 1 remaining blocker to getting this POC fully working on the devnet, as the devnet |
oplavande
changed the title
|
@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! |
|
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. |
|
@tynes is this the appropriate PR to track progress on? ethereum-optimism/op-geth#114 |
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.
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:
Tons of use cases become possible!
What is required to execute this Foundation Mission (RFP)?
Success criteria:
Recommended solution:
L1Blockpredeploy.How should the Foundation measure progress towards this Mission (RFP)?
Progress can be measured based upon the completion of the following milestones:
How should badgeholders measure impact upon completion of this Mission (RFP)?
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
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:
-- end of application --
The text was updated successfully, but these errors were encountered: