-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ethereum VM C interface #56
Comments
there should be p. 9, yellowpaper https://github.com/ethereum/libethereum/blob/develop/evmjit/include/evmjit/JIT-c.h#L35 |
also |
apart from that, LGTM 👍 |
I always tried to avoid |
@debris, any issues with input data being passed by pointer? It needs to be available on the Rust side all the time execution is in progress. Moreover, is it ok to timestamp being |
No
Yes 👍 |
@chfast At least in the interpreter gas and memory must be less than 2^63. There is no way on earth to use that much. If sometime in the future there is, this code will be long gone anyway. And otherwise gas and memory calculations become very slow, and gas calculations are almost pure overhead already. In the JIT perhaps the 256-bit operations can be optimized to 64-bit? |
I 100% agree. The problem is the spec allow the gas value to be very high and there are some tests in the test repo that exploits that. I agree that it makes no sense but users of evmjit usually complain that it does not pass all tests. Having gas limit of 2^63 make it fit in a regular CPU register and allows easy overflow detection. What I plan to do is to check the gas value in the first place and if it is less than 2^63 run the code in "fast" mode. Otherwise run in "compatibility" mode. |
The spec and the tests need to be fixed. Running in a separate mode just to pass tests means we have to write two interpreters and not test the one we actually run. Similar thing with memory. Conceptually it's infinite, but nobody can afford even a gigabyte, and it's not like you could allocate even 2^63 anyway. |
Let's propose lowering the maximum gas per transaction: #92. |
I try to design C interface for EVMJIT. Can you review ethereum/evmjit#55? |
@chfast these suggestions are based on latest interface as defined by
Also the |
For those interested, there's now an eWASM implementation using this C API: https://github.com/ewasm/hera |
@axic:
|
I'm not sure at this stage yet, whether that will be a viable solution.
They are not required, but why should they be disallowed doing so? Some VMs do provide the result with greater detail (ethereumjs, Parity). |
The generated docs are now auto-updated: http://ethereum.github.io/evmjit/docs/group__EVMC.html |
This is work in progress. I will update soon. |
Pinged @chfast to check into this. If it is still a WIP no problem, just want to get an update :) |
The live specification is maintained at https://github.com/ethereum/evmc. @chfast any point to keep this issue open? Should we create an ERC56 which has a copy of |
Motivation
Based on work done in EVM JIT project https://github.com/ethereum/evmjit I would like to propose C-like interface specification for Ethereum VM ABI that could be used to create high performance VM implementations.
Specification
Types
uint256be
- unsigned 256-bit big endian integer (32 bytes)uint256
- unsigned 256-bit host endian integer (32 bytes)uint64
- unsigned 64-bit host endian integer (8 bytes)int64
- signed 64-bit host endian integer (8 bytes)address
- Ethereum address (20 bytes)byte
- a byteptr
- a pointer to byte arrayInputs
codeget_code
query.code_sizeOutputs
Queries (aka Callbacks)
VM uses this query functions to get additional information from a Ethereum node.
uint256be keccak(ptr data, uint64 size)
uint256 balance(address)
BALANCE
instruction.uint256be blockhash(uint256 number)
BLOCKHASH
instruction.(ptr, uint64) extcode(address)
void log(ptr data, uint64 size, uint256be topic1, uint256be topic2, uint256be topic3, uint256be topic4)
uint256be sload(uint256be key)
void sstore(uint256be key, uint256be value)
sload
.bool call(...)
void create(...)
The text was updated successfully, but these errors were encountered: