aionnetwork / aion_fastvm Goto Github PK

I consider that when VM returns InternalError, such as OutOfMemory .etc, this node is under unreliable state. But in Java kernel, we just marked transaction as Failure.

Whether it is better to shutdown this node?

Do you mean uint256 is now uint?

https://github.com/aionnetwork/aion_fastvm/blob/master/solidity/tests/contracts/testAionToken.sol#L4

Description:

Need to implement functionality similar to ecrecover in Ethereum: precompiled contract + solidity compiler definitions.

Acceptance Criteria:

Should be able to validate / confirm an address in solidity code based on a message signed with the private key of the address.

In the current FastVM implementation, the value being transferred through transaction are not available to the callee contract. This has caused a few trouble for the Rust kernel implementation, due to a transaction on the Mastery testnet. See https://mastery.aion.network/#/transaction/ff8b53df5b06ee1e6569e437d83766ec747b331e7f2e92e6f3c38bffdec0cc99

Double checked the Ethereum's implementation, it seems that different clients have different implementation:

• Go-ethereum/Parity do the value transfer before the code execution
• EthereumJ do the value transfer after the code execution

In Aion, the value transfer after the code execution for the transactions; before the code execution for the CALL or CREATE opcodes. For consistency, I'd prefer to change the behavior for transaction, by conducting value transfer before code execution.

What is the use trivial test code in fastvm and how we can get it ? You people are mention inside the bench mark in FastVM repositories. if i paste the trivial code in the following file Vaion_fastvm/bench/evm/main.cpp then only i can get the result.

The NRG_CODE_POSIT is checked but not charged.

Also, only CREATE opcode is checked, and account creation transactions are not checked.

Based on EIP-161

Account creation transactions and the CREATE operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one.

However, in FastVM only the CREATE opcode case is covered; new accounts created by creation transactions will have an initial nonce of zero.

This should not affect normal solidity usage (contract with empty code is less common), but may end up with storage changes rollback for some edge cases. In the following example, the storage changes will be discarded because the newly created account is considered as empty.

{
  "name": "stack_push",
  "description": "can push items to stack",
  "transactions": [
    {
      "type": "CREATE",
      "receiver": "",
      "value": "0",
      "data": {
        "raw": "7f000000000000000000000000000000010000000000000000000000000000000255"
      },
      "nrg": "1000000"
    }
  ]
}

https://github.com/aionnetwork/aion/blob/843761824132b2dfe2a6e8dbc5b755167f571718/modAion/src/org/aion/zero/db/AionRepositoryCache.java#L64-L74

Error from line 5 of release.h:
cd .. && make jni && cd dist

Can't find jni.h. It was included line 2 of org_aion_fastvm_FastVM.h

Can't find jin.h

DApp developers will get the following error message, if there are too many local variables.

Stack too deep, try removing local variables.

This is a common issue for stack-based virtual machine, specifically FastVM and EVM. Only the top N stack items can be read/written; therefore, all high level languages on top of it has to limit the number of local variables which are stored on the stack.

Both Aion and Ethereum's solidity have the same limit on number of local stack items where local variables can occupate. However, the actual number of local variables are typically less in Aion's platfrom, because some local variable may take more than one stack item. For example, variable of address type will take two 128-bit stack items in Aion, while only one 256-bit stack item in Ethereum.

I believe the only solution to make Aion Solidity support more local variables is to update the FastVM by:

• Introduce DUP17-DUP32 and SWAP17-SWAP32;
• OR add new opcodes DUPX and SWAPX which take on argument specifying the N-th stack item to operate on.
• OR add new opcodes DUP + (1 byte offset) and SWAP + (1 byte offset) which take a number of arguments as specified in the next byte.