A sea view coffee shop in Jeju with best chocolate bun!

Greetings, people! It's time for another round of development updates!

As 🌞 the weather heats up and summer approaches, the Axon team has been hard at work on some exciting new accomplishments that are sure to beat the heat.

Take a moment to 🆒 off and explore the latest wonders we've conjured up!

✅What we’ve done

✨We've developed the Axon proxy, a reverse proxy for Axon. It boasts a variety of impressive features, such as the support for HTTP and WebSocket protocols. With offering advanced load balancing including power of two choices (P2C) least requests and client IP consistent hashing, it ensures high availability deployment.

✨Some refinements to increase efficiency, flexibility, and scalability of Axon framework:

• Utilized a read buffer to minimize input/output (io) costs to increase efficiency and reduce costs associated with storing data . #1227
• Added support for custom event serialization and deserialization in the Axon Framework. #1229
• Restricted the maximum block range for obtaining a lock in order to prevent distributed denial-of-service (DDoS) attack. #1230
• Fixed block ID H256 from hexadecimal. #1231

🏃‍♂️ What we're up to:

• We will continue to focus on improving staking-related transactions
• We plan to implement the debug_transactionTrace interface by adding EVM trace to implement the debug_transactionTrace interface, adding tracing functionality for EVM to help with debugging.
• We’ll also refactor axon-cli, to improve Axon user experience.
• 👬👯‍♀️One of our engineers has been invited to give a speech on “Developing and practicing Axon Appchain Framework in Rust” at @RustconfChina in Shanghai. Hope to see you there!

query:

{
	"jsonrpc":"2.0",
	"method":"eth_getBalance",
	"params":[
		"0xf4cc1652dcec2e5de9ce6fb1b6f9fa9456e957f1", 
		"0x618"
	],
	"id":1
}

result:

{
    "jsonrpc": "2.0",
    "error": {
        "code": -32001,
        "message": "Custom error: [ProtocolError] Kind: API Error: Adapter(\"Cannot get 0xf4cc1652dcec2e5de9ce6fb1b6f9fa9456e957f1 account\")"
    },
    "id": 1
}

What happened:

eth_getLogs returns "address" of the account which sent transaction instead of the address of the contract that emitted event.

What you expected to happen:

eth_getLogs returns "address" of the actual contract that emitted event. It seems eth_getTransactionReceipt returns events correctly.

How to reproduce it (as minimally and precisely as possible):

curl --location --request POST 'http://34.204.204.212:8000' \
--header 'Content-Type: application/json' \
--data-raw '{
  "jsonrpc": "2.0",
  "id": 0,
  "method": "eth_getLogs",
  "params": [
    {
      "fromBlock": "0x732a",
      "toBlock": "0x733f"
    }
  ]
}'

returns wrong address (everywhere the transaction sender instead of contract address, default hardhat account):

{
    "jsonrpc": "2.0",
    "result": [
        {
            "address": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
            "topics": [
                "0xa9ba3ffe0b6c366b81232caab38605a0699ad5398d6cce76f91ee809e322dafc"
            ],
            "data": "0x00000000000000000000000000000000000000000000000000038d7ea4c68000",
            "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
            "blockNumber": "0x732f",
            "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
            "transactionIndex": "0x0",
            "logIndex": "0x0",
            "removed": false
        },
        {
            "address": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
            "topics": [
                "0x3c13bc30b8e878c53fd2a36b679409c073afd75950be43d8858768e956fbc20e",
                "0x1881d02d05a44713a69d6edde3e7167792a636d6000200000000000000000003",
                "0x0000000000000000000000001881d02d05a44713a69d6edde3e7167792a636d6"
            ],
            "data": "0x0000000000000000000000000000000000000000000000000000000000000002",
            "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
            "blockNumber": "0x732f",
            "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
            "transactionIndex": "0x0",
            "logIndex": "0x1",
            "removed": false
        },
        {
            "address": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
            "topics": [
                "0xf5847d3f2197b16cdcd2098ec95d0905cd1abdaf415f07bb7cef2bba8ac5dec4",
                "0x1881d02d05a44713a69d6edde3e7167792a636d6000200000000000000000003"
            ],
            "data": "0x000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000020000000000000000000000007a2088a1bfc9d81c55368ae168c2c02570cb814f000000000000000000000000c5a5c42992decbae36851359345fe25997f5c42d000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
            "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
            "blockNumber": "0x732f",
            "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
            "transactionIndex": "0x0",
            "logIndex": "0x2",
            "removed": false
        },
        {
            "address": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
            "topics": [
                "0x1835882ee7a34ac194f717a35e09bb1d24c82a3b9d854ab6c9749525b714cdf2"
            ],
            "data": "0x00000000000000000000000000000000000000000000000000000000000186a000000000000000000000000000000000000000000000000000000000000186a0000000000000000000000000000000000000000000000000000000006329b49c000000000000000000000000000000000000000000000000000000006329b49c",
            "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
            "blockNumber": "0x732f",
            "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
            "transactionIndex": "0x0",
            "logIndex": "0x3",
            "removed": false
        },
        {
            "address": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
            "topics": [
                "0xa0d01593e47e69d07e0ccd87bece09411e07dd1ed40ca8f2e7af2976542a0233"
            ],
            "data": "0x00000000000000000000000000000000000000000000000000000000000186a0",
            "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
            "blockNumber": "0x732f",
            "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
            "transactionIndex": "0x0",
            "logIndex": "0x4",
            "removed": false
        },
        {
            "address": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
            "topics": [
                "0x83a48fbcfc991335314e74d0496aab6a1987e992ddc85dddbcc4d6dd6ef2e9fc",
                "0x0000000000000000000000001881d02d05a44713a69d6edde3e7167792a636d6"
            ],
            "data": "0x",
            "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
            "blockNumber": "0x732f",
            "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
            "transactionIndex": "0x0",
            "logIndex": "0x5",
            "removed": false
        }
    ],
    "id": 0
}

but eth_getTransactionReceipt returns correct address of the event emitter:

request:

curl --location --request POST 'http://34.204.204.212:8000' \
--header 'Content-Type: application/json' \
--data-raw '{
  "jsonrpc": "2.0",
  "id": 0,
  "method": "eth_getTransactionReceipt",
  "params": [
    "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf"
  ]
}'

response:

{
    "jsonrpc": "2.0",
    "result": {
        "blockNumber": "0x732f",
        "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
        "contractAddress": null,
        "cumulativeGasUsed": "0x3c9069",
        "effectiveGasPrice": "0x3c9069",
        "from": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
        "gasUsed": "0x3c9069",
        "logs": [
            {
                "address": "0x1881d02d05a44713a69d6edde3e7167792a636d6",
                "topics": [
                    "0xa9ba3ffe0b6c366b81232caab38605a0699ad5398d6cce76f91ee809e322dafc"
                ],
                "data": "0x00000000000000000000000000000000000000000000000000038d7ea4c68000",
                "blockNumber": "0x732f",
                "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
                "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
                "transactionIndex": "0x0",
                "logIndex": "0x0",
                "removed": false
            },
            {
                "address": "0xb7f8bc63bbcad18155201308c8f3540b07f84f5e",
                "topics": [
                    "0x3c13bc30b8e878c53fd2a36b679409c073afd75950be43d8858768e956fbc20e",
                    "0x1881d02d05a44713a69d6edde3e7167792a636d6000200000000000000000003",
                    "0x0000000000000000000000001881d02d05a44713a69d6edde3e7167792a636d6"
                ],
                "data": "0x0000000000000000000000000000000000000000000000000000000000000002",
                "blockNumber": "0x732f",
                "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
                "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
                "transactionIndex": "0x0",
                "logIndex": "0x1",
                "removed": false
            },
            {
                "address": "0xb7f8bc63bbcad18155201308c8f3540b07f84f5e",
                "topics": [
                    "0xf5847d3f2197b16cdcd2098ec95d0905cd1abdaf415f07bb7cef2bba8ac5dec4",
                    "0x1881d02d05a44713a69d6edde3e7167792a636d6000200000000000000000003"
                ],
                "data": "0x000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000020000000000000000000000007a2088a1bfc9d81c55368ae168c2c02570cb814f000000000000000000000000c5a5c42992decbae36851359345fe25997f5c42d000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
                "blockNumber": "0x732f",
                "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
                "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
                "transactionIndex": "0x0",
                "logIndex": "0x2",
                "removed": false
            },
            {
                "address": "0x1881d02d05a44713a69d6edde3e7167792a636d6",
                "topics": [
                    "0x1835882ee7a34ac194f717a35e09bb1d24c82a3b9d854ab6c9749525b714cdf2"
                ],
                "data": "0x00000000000000000000000000000000000000000000000000000000000186a000000000000000000000000000000000000000000000000000000000000186a0000000000000000000000000000000000000000000000000000000006329b49c000000000000000000000000000000000000000000000000000000006329b49c",
                "blockNumber": "0x732f",
                "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
                "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
                "transactionIndex": "0x0",
                "logIndex": "0x3",
                "removed": false
            },
            {
                "address": "0x1881d02d05a44713a69d6edde3e7167792a636d6",
                "topics": [
                    "0xa0d01593e47e69d07e0ccd87bece09411e07dd1ed40ca8f2e7af2976542a0233"
                ],
                "data": "0x00000000000000000000000000000000000000000000000000000000000186a0",
                "blockNumber": "0x732f",
                "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
                "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
                "transactionIndex": "0x0",
                "logIndex": "0x4",
                "removed": false
            },
            {
                "address": "0x0dcd1bf9a1b36ce34237eeafef220932846bcd82",
                "topics": [
                    "0x83a48fbcfc991335314e74d0496aab6a1987e992ddc85dddbcc4d6dd6ef2e9fc",
                    "0x0000000000000000000000001881d02d05a44713a69d6edde3e7167792a636d6"
                ],
                "data": "0x",
                "blockNumber": "0x732f",
                "blockHash": "0x16cc2b69d32f787d0d6fa4816ea50bfd4561d08a6af1728a71d75cd787633f64",
                "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
                "transactionIndex": "0x0",
                "logIndex": "0x5",
                "removed": false
            }
        ],
        "logsBloom": "0x00000000100000000000020000000000020000000040000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000004000000000000000000000000008d000000000000000000800004000000040000000000000000000000000000000000000000000000000100200000000000000000000000000000000000000000002000004000200000000000000008000000000000000000000000000000000008000120000000000011000000000400040008000000000000000000000000000000000000000000000000000000000000200000000000000000040000000000a0000020000000000000000010000",
        "root": "0x216440829aa06f90a26b6eb812dfcfe0f6a99053a74c9750dcedb49589ff18bb",
        "status": "0x1",
        "to": "0x0dcd1bf9a1b36ce34237eeafef220932846bcd82",
        "transactionHash": "0xbe5eebfd04a45999c3b37e99edb85c08988ecd512b593caafa2944df54ea36bf",
        "transactionIndex": "0x0",
        "type": "0x0"
    },
    "id": 0
}

Additional information:
According to Ethereum spec (https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterchanges) event address should be: "address from which this log originated." - not the receipt.sender.

I think Axon filtering of eth_getLogs by using "address" parameter is also wrong and needs to be fixed in "core/api/src/jsonrpc/impl/web3.rs".

Environment:

:~/axon/axon$ git log -1
commit cd76bd7b03a29782b5f96e4946126a352e917304 (HEAD -> main, origin/main, origin/HEAD)
Author: michaelbruz <[email protected]>
Date:   Mon Sep 19 17:43:15 2022 +0800

    feat(ibc): impl ibc adapter traits (#720)

    Signed-off-by: dependabot[bot] <[email protected]>
    Co-authored-by: Eason Gao <[email protected]>
    Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
    Co-authored-by: cryptape.michael <[email protected]>

We are redesigning the Axon logo, sincerely welcome to provide your creativity. Just submit your ideas below and do not forget a short description.

What happened:

eth_getLogs filtering events by address is filtering by transaction receipts address instead of individual logs address.

What you expected to happen:

eth_getLogs filtering events by address is filtering logs instead of transaction receipts

Right now filtering events in Axon is checking receipt.code_address against address filter in eth_getLogs. I think this is wrong and address filter should be checked against each log.address instead. In one transaction there can be internal calls and events emitted from MULTIPLE contract addresses, therefore logs can be emitted from different addresses and I think that's why filtering logic in Axon should operate on logs instead of receipts.

Check this code please: https://github.com/axonweb3/axon/blob/main/core/api/src/jsonrpc/impl/web3.rs#L451

What happened:

Graph Node eth_call calls by default don't work with Axon because Axon default eth_call gas limit is 30 million.

What you expected to happen:

Axon default eth_call gas limit is at least 50 million.

How to reproduce it (as minimally and precisely as possible):

Run any subgraph on graph-node that does eth_calls or send eth_call with gas limit = 50 million. Axon will error.

Additional information

/// Gas limit for eth_call. The value of 50_000_000 is a protocol-wide parameter so this
/// should be changed only for debugging purposes and never on an indexer in the network. This
/// value was chosen because it is the Geth default
/// https://github.com/ethereum/go-ethereum/blob/e4b687cf462870538743b3218906940ae590e7fd/eth/ethconfig/config.go#L91.
/// It is not safe to set something higher because Geth will silently override the gas limit
/// with the default. This means that we do not support indexing against a Geth node with
/// RPCGasCap set below 50 million.

Source: https://github.com/graphprotocol/graph-node/blob/5009effd4b5947d45fb76506cdb34c5b9fcb4b5a/chain/ethereum/src/ethereum_adapter.rs#L77

Changing Axon gas limit to 50 million results in working graph-node. I've tested it with Moloch V2 events.

What happened:
In Javascript/Web3 case，we use transaction nonce as BigNumber type and so as we use this nonce to create contract address. Most of time it works fine wether the nonce is BigNumber type or normal type, but except the "nonce = 0" as I can find so far.

We can tell:

if the nonce = 0 is normal type:
contract address of administrator of Axon is 0xa13763691970d9373d4fab7cc323d7ba06fa9986 (which is used by current Axon implementation)

if the nonce = 0 is BigNumber type:
contract address of administrator of Axon is 0x037d28ae1969b75a4d19ced217bf9f4bc611b446 (which I think is the right way to generate contract address)

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:
the only difference I found is happened in "nonce = 0" case, but I can't tell other cases won't meet this kind of difference, it should be careful to deal.

Environment:

• Mercury version or commit hash (git log -1):
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Others:

Contact Details

[email protected]

Propose-a-new-feature

Describe the solution you'd like:

Problem Statement

Axon nodes are required to have access to sep256k1 key in order to make authenticated peer connections. However , the currently codebase does not lend itself to security best practices , as these keys are currently exposed transparently in the node's config file .

Proposed Solution

Axon using ethers.rs , which implement the AWS Signer.

Implementation

Inspiration for implementing the AWS signer can be taken from here

Alternatives you've considered

As we use kuberenetes for our set up , we could store them as encrypted secrets , but this presents two issues

1. Secrets are base64 encoded.
2. Even with Secret Manager , the axon nodes have no way of parsing these secrets

Anything else?

This is a blocker to going to production and would appreciate your assistance with it.

What happened:

We are trying to send transactions to our node using the eth_sendRawTransaction json rpc end point. When we try calling it via the command line / postman , we get the following error

FetchError: request to http://34.204.204.212:8000/ failed, reason: socket hang up

Upon inspecting the logs , we need that the json rpc server is crashing and causing the program to panic : https://gist.github.com/samtvlabs/c8b3134675c481080231bb329a3644b4

What you expected to happen:

The transaction should be successful and return a transaction hash.

How to reproduce it (as minimally and precisely as possible):

• build a release version of the code master branch

cargo build release

• Start axon

target/release/axon -c devtools/chain/config.toml -g devtools/chain/genesis_single_node.json

• make this rpc call via postman or curl

curl --location --request POST 'localhost:8000/' \
--header 'Content-Type: application/json' \
--data-raw '{
	"jsonrpc":"2.0",
	"method":"eth_sendRawTransaction",
	"params":["0xf9043f098502540be4008344f74d8080b9042c60806040526100163364010000000061001b810204565b61003d565b60068054600160a060020a031916600160a060020a0392909216919091179055565b6103e08061004c6000396000f3006080604052600436106100775763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416633ad06d1681146100c257806354fd4d50146100e85780635c60da1b1461010f5780636fde820214610140578063a9c45fcb14610155578063f1739cae14610179575b600061008161019a565b9050600160a060020a038116151561009857600080fd5b60405136600082376000803683855af43d82016040523d6000833e8080156100be573d83f35b3d83fd5b3480156100ce57600080fd5b506100e6600435600160a060020a03602435166101a9565b005b3480156100f457600080fd5b506100fd6101d3565b60408051918252519081900360200190f35b34801561011b57600080fd5b5061012461019a565b60408051600160a060020a039092168252519081900360200190f35b34801561014c57600080fd5b506101246101d9565b6100e6600480359060248035600160a060020a0316916044359182019101356101e8565b34801561018557600080fd5b506100e6600160a060020a0360043516610250565b600854600160a060020a031690565b6101b16101d9565b600160a060020a031633146101c557600080fd5b6101cf82826102d8565b5050565b60075490565b600654600160a060020a031690565b6101f06101d9565b600160a060020a0316331461020457600080fd5b61020e84846101a9565b30600160a060020a03163483836040518083838082843782019150509250505060006040518083038185875af192505050151561024a57600080fd5b50505050565b6102586101d9565b600160a060020a0316331461026c57600080fd5b600160a060020a038116151561028157600080fd5b7f5a3e66efaa1e445ebd894728a69d6959842ea1e97bd79b892797106e270efcd96102aa6101d9565b60408051600160a060020a03928316815291841660208301528051918290030190a16102d58161037d565b50565b600854600160a060020a03828116911614156102f357600080fd5b6102fc816103ac565b151561030757600080fd5b600754821161031557600080fd5b600782905560088054600160a060020a03831673ffffffffffffffffffffffffffffffffffffffff1990911681179091556040805184815290517f4289d6195cf3c2d2174adf98d0e19d4d2d08887995b99cb7b100e7ffe795820e9181900360200190a25050565b6006805473ffffffffffffffffffffffffffffffffffffffff1916600160a060020a0392909216919091179055565b6000903b11905600a165627a7a72305820367593e912fa4bfc7d8aa365738abd53d47d9e399bca3a9e7859539be7ec86580029808080"],
	"id":1
}'

Anything else we need to know?:

Environment:

• Mercury version or commit hash (git log -1): 162e179
• OS (e.g: cat /etc/os-release):

PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

• Kernel (e.g. uname -a):

Linux ip-172-31-70-167 5.15.0-1019-aws #23-Ubuntu SMP Wed Aug 17 18:33:13 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

• Others:

What happened:

通过 'ethers' 库发起的调用 eth_sendRawTransaction 接口返回错误信息，但这个错误信息并不是每次都会出现，比较有可能的发生规律是在上一笔交易上链后不久再发起下一笔交易，很容易出现该问题，过一段时间再试便没有问题

What you expected to happen:
交易成功上链

How to reproduce it (as minimally and precisely as possible):

1. 下载 axon-bridge-ui 库 (https://github.com/nervosnetwork/axon-bridge-ui)
2. 多次发起 axon => ckb 方向上的跨链交易

Anything else we need to know?:

Environment:

• Mercury version or commit hash (git log -1):
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Others:

Contact Details

No response

Current Behavior

The state root of the same genesis block should be the same.

But when run Axon with v0.1.0-beta.5, it returns a different state root with v0.1.0-beta.0.

Expected Behavior

I used git bisect to create a empty dev chain and checked the state root of its genesis block again and again, and finally I found the state root was changed between commit 5819560 and dd629ee.

The state root of the dev chain (ref: devtools/chain) I got through JSON-RPC:

• Before commit 5819560 (included): 0x13d66227ff58a309512520b553454300483111ae4d3cfe7c39af2f12047f8893
• After commit dd629ee (included): 0x65f57a6a666e656de33ed68957e04b35b3fe1b35a90f6eafb6f283c907dc3d77

OS

Not Associated

Axon version

v0.1.0-beta.x

Kernel

Not Associated

Relevant log output

No log output.

Anything else?

• Was the changed state root is as expected?
• There should be some checks in CI.

Propose-a-new-feature

For now CKB precompiled contract only provides method getCell(bytes32 txHash, uint32 index) for other contract to use (see here). We probably need more methods for proof verification in IBC, for example

• getLiveCells(Height height)
• getLatestHeight

The specific methods we need are not confirmed until CKB hardfork has been launched. This issue is for track and discussion.

cc @ashuralyk

use for block reward

track_block method supported by parity, but not supported by geth
https://www.quicknode.com/docs/ethereum/trace_block

Contact Details

No response

Current Behavior

Problem

Axon node implements eth_feeHistory RPC endpoint but returns "reward": null field.

For example, given a curl:

curl -X POST --location "http://localhost:10002" \
    -H "Content-Type: application/json" \
    -d "{
          \"id\": 1,
          \"jsonrpc\": \"2.0\",
          \"method\": \"eth_feeHistory\",
          \"params\": [
            \"0x10\",
            \"latest\"
          ]
        }"

according to this line:

the response is:

{
  "jsonrpc": "2.0",
  "result": {
    "oldestBlock": "0x0",
    "reward": null,
    "baseFeePerGas": [],
    "gasUsedRatio": []
  },
  "id": 1
}

Some JSON RPC clients are not ready for null value and fail to parse the response.

For example, I use Foundry's cast send command to my local node:

cast send 0xdc796dfc1bb45f21d17be267877c3388d766937b --value 1234 --rpc-url http://localhost:10002 --private-key 0x37aa0f893d05914a4def0460c0a984d3611546cfb26924d7a7ca6e0db9950a2d

it fails with the following error:

Deserialization Error: invalid type: null, expected a sequence at line 1 column 34. Response: {"oldestBlock":"0x0","reward":null,"baseFeePerGas":[],"gasUsedRatio":[]}

Solution

Exclude null values from responses. The Ethereum RPC spec is not strict on the return results but I suppose null values should be ommitted.

Expected Behavior

Expected Behavior:

OS

MacOS

Axon version

No response

Kernel

MacOS

Relevant log output

No response

Anything else?

No response

Contact Details

[email protected]

Propose-a-new-feature

axon/common/apm-derive/examples/api.rs

#[async_trait]
impl Rpc for RpcExample {
    #[metrics_rpc("eth_sendRawTransaction")]
    async fn send_transaction(&self, tx: SignedTransaction) -> Result<Hash, Error> {
        Ok(tx.transaction.hash)
    }

    #[metrics_rpc("net_listening")]
    fn listening(&self) -> Result<bool, Error> {
        Ok(false)
    }
}

macro metrics_rpc only support IntCounter type in Prometheus

Alternatives you've considered

Describe alternatives you've considered:
extend the macro to support CounterVec, Gauge, IntGaugeVec, and other types.

Anything else?

No response

Random shot of a blossom tree that reminds me of this poem:

Gather ye rosebuds while ye may,
For having lost but once your prime,
You may forever tarry.

Picture taken in Kyoto, 2021.

What we have accomplished

• In the previous weeks, we completed the development of ICSC. ICSC significantly extends the interoperability of Axon. This week, we have discussed how to construct interoperation transaction signatures internally. #896 introduces the principle of interoperation transaction that is compatible with the Ethereum transaction structure.
• We keep elaborating on Gasless Transaction #899.
• We have debugged the cell-emitter and ICSC without using the IBC relayer. In the process, we fixed a bug on block number storage #978, and refactored the error define #981.
• We added a new issue reply workflow, welcome to communicate with us through issue.

What we are doing

• The gasless implement pull request #960 is still in review. Your feedback is welcome!
• Staking and election #898 is the most important task in present. We are in the midst of intensive discussions to finalize the design, and we need your advice here as well.

January 21 is the Chinese Lunar New Year. Happy Lunar New Year and we’ll see you on February 8th.

Hi, Is there some reason for gas_used: 1u64,of that step, or it`s just Ethereum's regulations?

Forbidden City corner tower!

Picture taken in Beijing, 2018

Hi folks, here's a summary of our recent accomplishments and ongoing work:

What we have accomplished

• We fix two intricate bug that may cost some metadata lost and break to synchronization, this will improve the robustness of Axon
  • #1245
  • #1264
• Upgraded the solidity version of built-in contract to 0.8.20#1263
• Bumped faster-hex to 0.8 #1266
• Several updates on Spark:
  • Developed and merged witness build function, filled in some witness and added test cases for tx. Details can be found in the following pull requests:
    • axonweb3/spark#35
    • axonweb3/spark#38
    • axonweb3/spark#36
    • axonweb3/spark#39
• Enhanced the font style of the documentation site axonweb3/axon-docs#171

What we are doing

• Our focus remains on improving staking-related transactions.
• Removing useless sub-commands and will be adding more later.
  #1269

Stay tuned for more!

What happened:

When trying to send raw transactions , we encounter this error:

Error: web3 RPC failed: {"code":-32001,"message":"Custom error: [ProtocolError] Kind: Types Error: TxHashMismatch { origin: 0xede84189f814dad023f7dfc986bc2e0573bf9fa0ac24baed321471cf370102a0, calc: 0xb6331134996b4acde9814fc445e26061ef3b13148c3a50cad67d453174bf9bed }"}
    at sendNodeRequest (/Users/samueldare/Parity/tokenbridge-contracts/deploy/src/deploymentUtils.js:161:9)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async sendRawTx (/Users/samueldare/Parity/tokenbridge-contracts/deploy/src/deploymentUtils.js:130:20)
    at async deployContract (/Users/samueldare/Parity/tokenbridge-contracts/deploy/src/deploymentUtils.js:55:14)
    at async deployHome (/Users/samueldare/Parity/tokenbridge-contracts/deploy/src/arbitrary_message/home.js:82:33)
    at async deployArbitraryMessage (/Users/samueldare/Parity/tokenbridge-contracts/deploy/deploy.js:39:26)
    at async main (/Users/samueldare/Parity/tokenbridge-contracts/deploy/deploy.js:90:7)
Error: TypeError: Cannot read property 'status' of undefined
    at deployContract (/Users/samueldare/Parity/tokenbridge-contracts/deploy/src/deploymentUtils.js:63:32)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async deployHome (/Users/samueldare/Parity/tokenbridge-contracts/deploy/src/arbitrary_message/home.js:82:33)
    at async deployArbitraryMessage (/Users/samueldare/Parity/tokenbridge-contracts/deploy/deploy.js:39:26)
    at async main (/Users/samueldare/Parity/tokenbridge-contracts/deploy/deploy.js:90:7)

The axon RPC seems to be mutating the hash and causing this error.

What you expected to happen:

Transaction should be successful.

How to reproduce it (as minimally and precisely as possible):

• Run this

Anything else we need to know?:

Environment:

Darwin Kernel Version 21.6.0: Mon Aug 22 20:19:52 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T6000 x86_64

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Mercury version or commit hash (git log -1):
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Others:

What happened:

Trying to get a transaction from the internal testing node with 0x8612c1833c6bc876ac1389b65831adb5cbb662734492dafb9906cc7f1a29d6be which is listed in the genesis block, but get an error Custom error: can not get receipt by hash 0x8612c1833c6bc876ac1389b65831adb5cbb662734492dafb9906cc7f1a29d6be

What you expected to happen:
A valid transaction returned

Or null returned if the transaction is not found

Contact Details

No response

Current Behavior

Summary

If "Axon is compatible with Ethereum" as that written in the README.md, the implementation of receipts root in block is incorrect.

Details

• The Block::receipts_root is set from ExecResp.receipt_root.

  axon/protocol/src/types/block.rs

  Line 118 in c7a471b

  receipts_root: exec_resp.receipt_root,

• The ExecResp.receipt_root is merkle root of a list of hashes.

  axon/core/executor/src/lib.rs

  Lines 175 to 182 in c7a471b

  	ExecResp {
  	state_root: new_state_root,
  	receipt_root: TrieMerkle::from_iter(hashes.iter().enumerate())
  	.root_hash()
  	.unwrap_or_default(),
  	gas_used: gas,
  	tx_resp: res,
  	}

• Each hash in hashes is AxonExecutor::evm_exec(...).ret.

  axon/core/executor/src/lib.rs

  Lines 142 to 149 in c7a471b

  	let mut r = system_contract_dispatch(adapter, tx)
  	.unwrap_or_else(|| Self::evm_exec(adapter, &config, &precompiles, tx));
  	r.logs = adapter.get_logs();
  	gas += r.gas_used;
  	fee = fee.checked_add(r.fee_cost).unwrap_or(U256::max_value());
  	hashes.push(Hasher::digest(&r.ret));

• TxResp.ret is set from res.

  axon/core/executor/src/lib.rs

  Lines 282 to 284 in c7a471b

  	TxResp {
  	exit_reason: exit,
  	ret: res,

• The res is transact_call(...).1

  axon/core/executor/src/lib.rs

  Lines 232 to 248 in c7a471b

  	let (exit, res) = match tx.transaction.unsigned.action() {
  	TransactionAction::Call(addr) => executor.transact_call(
  	tx.sender,
  	*addr,
  	*tx.transaction.unsigned.value(),
  	tx.transaction.unsigned.data().to_vec(),
  	gas_limit.as_u64(),
  	access_list,
  	),
  	TransactionAction::Create => executor.transact_create(
  	tx.sender,
  	*tx.transaction.unsigned.value(),
  	tx.transaction.unsigned.data().to_vec(),
  	gas_limit.as_u64(),
  	access_list,
  	),
  	};

• So, the res is just Vec<u8> which represents the return data of the called contract, it is NOT the receipt of transaction.

Expected Behavior

None.

OS

Not Associated

Axon version

No response

Kernel

Not Associated

Relevant log output

No response

Anything else?

p.s. I don't like your issue template, at least it's not suitable for this issue.

Contact Details

No response

What happened

I test the Axon nodes deployment to Kubernetes on my local machine, using a patch of axon-devops to use local machine PersistentVolumes.

• I set replicaSet = 1 for each StatefulSet for simplicity.
• I deployed 4 default nodes to k8s, blockchain was working fine and producing blocks.
• I wanted to test if Axon can recover after scaling down StatefulSet replicas to 0 and then to 1 again, so I ran these commands:

kubectl scale statefulsets --namespace axon axon1 --replicas=0
kubectl scale statefulsets --namespace axon axon2 --replicas=0
kubectl scale statefulsets --namespace axon axon3 --replicas=0
kubectl scale statefulsets --namespace axon axon4 --replicas=0

< waited 1 minute >
kubectl scale statefulsets --namespace axon axon1 --replicas=1
kubectl scale statefulsets --namespace axon axon2 --replicas=1
kubectl scale statefulsets --namespace axon axon3 --replicas=1
kubectl scale statefulsets --namespace axon axon4 --replicas=1

Axon pods started fine from K8s point of view, but were not producing blocks. Logs of each of the 4 pods:
axon-node1:

[2023-04-19T16:16:38.682164423+00:00 INFO core_run] The Genesis block has been initialized.
[2023-04-19T16:16:39.003398798+00:00 INFO core_run] prometheus start
[2023-04-19T16:16:39.003467882+00:00 INFO core_run] node starts
[2023-04-19T16:16:39.003578507+00:00 INFO core_run] Data path for block: "./devtools/chain/data1/rocksdb/block_data"
[2023-04-19T16:16:40.535005382+00:00 INFO core_run] Recover 0 tx of number 177843 from wal
[2023-04-19T16:16:41.440287549+00:00 INFO core_network::service] listen start at: /ip4/0.0.0.0/tcp/8001
[2023-04-19T16:16:41.440544549+00:00 INFO overlord::overlord] Overlord start running
[2023-04-19T16:16:41.446114633+00:00 INFO overlord::state::process] overlord: start from wal wal info height 177843, round 3, step Brake
[2023-04-19T16:16:41.446162841+00:00 INFO overlord::state::process] Overlord: "0232c489c23b1207107e9a24648c1e4754a8c1c0b38db96df57a526201035058cb" become leader, height 177843, round 3
[2023-04-19T16:16:41.454014591+00:00 INFO overlord::state::collection] Overlord: 1 chokes in round 3, voters ["031ddc35212b7fc7ff6685b17d91f77c972535aee5c7ae5684d3e72b986f08834b"]
[2023-04-19T16:16:41.457753341+00:00 INFO core_network::protocols::transmitter] ProtocolId(4) open on SessionId(2), addr: /dns4/axon3/tcp/8001/p2p/QmQLufVVmBuHKoYhdDCqUFYVtLYs1quryoaA1mkQYQdWkn
[2023-04-19T16:16:41.498802591+00:00 INFO core_network::protocols::discovery] get discovery addr len: 0
[2023-04-19T16:16:41.499078924+00:00 INFO core_network::protocols::transmitter] ProtocolId(4) open on SessionId(1), addr: /dns4/axon2/tcp/8001/p2p/QmaHBJqULbLGDn7Td196goNebH6XMTMMu2sKNNP2DiX9S2
[2023-04-19T16:16:41.541955716+00:00 INFO core_network::protocols::discovery] get discovery addr len: 0
[2023-04-19T16:16:41.774677925+00:00 INFO overlord::state::collection] Overlord: 2 chokes in round 3, voters ["031ddc35212b7fc7ff6685b17d91f77c972535aee5c7ae5684d3e72b986f08834b", "02b77c74eb68af3d4d6cc7884ed6709f1a2a1af0f713382a4438ec2ea3a70d4d7f"]
[2023-04-19T16:16:44.459548217+00:00 INFO overlord::state::collection] Overlord: 2 chokes in round 3, voters ["031ddc35212b7fc7ff6685b17d91f77c972535aee5c7ae5684d3e72b986f08834b", "02b77c74eb68af3d4d6cc7884ed6709f1a2a1af0f713382a4438ec2ea3a70d4d7f"]
[2023-04-19T16:16:44.775983301+00:00 INFO overlord::state::collection] Overlord: 2 chokes in round 3, voters ["031ddc35212b7fc7ff6685b17d91f77c972535aee5c7ae5684d3e72b986f08834b", "02b77c74eb68af3d4d6cc7884ed6709f1a2a1af0f713382a4438ec2ea3a70d4d7f"]
[2023-04-19T16:16:46.188240760+00:00 INFO core_network::protocols::transmitter] ProtocolId(4) open on SessionId(3), addr: /ip4/10.1.10.192/tcp/8001/p2p/QmXoSkz4zkHHiFZqmDZQ4gFYtJ72uqtp4m6FX373X4VkRq
[2023-04-19T16:16:47.460930344+00:00 INFO overlord::state::collection] Overlord: 2 chokes in round 3, voters ["031ddc35212b7fc7ff6685b17d91f77c972535aee5c7ae5684d3e72b986f08834b", "02b77c74eb68af3d4d6cc7884ed6709f1a2a1af0f713382a4438ec2ea3a70d4d7f"]
[2023-04-19T16:16:47.778333802+00:00 INFO overlord::state::collection] Overlord: 2 chokes in round 3, voters ["031ddc35212b7fc7ff6685b17d91f77c972535aee5c7ae5684d3e72b986f08834b", "02b77c74eb68af3d4d6cc7884ed6709f1a2a1af0f713382a4438ec2ea3a70d4d7f"]
< the same message x100 more times>

axon-node2 logs are identical to axon-node1.

axon-node3:

[2023-04-19T16:16:37.240204881+00:00 INFO core_run] The Genesis block has been initialized.
[2023-04-19T16:16:37.791203798+00:00 INFO core_run] prometheus start
[2023-04-19T16:16:37.791310881+00:00 INFO core_run] node starts
[2023-04-19T16:16:37.791468631+00:00 INFO core_run] Data path for block: "./devtools/chain/data3/rocksdb/block_data"
[2023-04-19T16:16:38.986820007+00:00 INFO core_run] Recover 0 tx of number 177843 from wal
[2023-04-19T16:16:39.807693465+00:00 INFO core_network::service] listen start at: /ip4/0.0.0.0/tcp/8001
[2023-04-19T16:16:39.808462715+00:00 INFO overlord::overlord] Overlord start running
[2023-04-19T16:16:41.457260883+00:00 INFO core_network::protocols::transmitter] ProtocolId(4) open on SessionId(1), addr: /ip4/10.1.10.191/tcp/8001/p2p/QmNk6bBwkLPuqnsrtxpp819XLZY3ymgjs3p1nKtxBVgqxj
[2023-04-19T16:16:46.147298010+00:00 INFO core_network::protocols::transmitter] ProtocolId(4) open on SessionId(2), addr: /ip4/10.1.10.192/tcp/8001/p2p/QmXoSkz4zkHHiFZqmDZQ4gFYtJ72uqtp4m6FX373X4VkRq
[2023-04-19T16:17:08.757434381+00:00 INFO core_network::protocols::transmitter] ProtocolId(4) open on SessionId(3), addr: /ip4/10.1.10.189/tcp/8001/p2p/QmaHBJqULbLGDn7Td196goNebH6XMTMMu2sKNNP2DiX9S2
[2023-04-19T16:18:38.757924840+00:00 INFO core_network::protocols::discovery] get discovery addr len: 2
[2023-04-19T16:18:41.445230508+00:00 INFO core_network::protocols::discovery] get discovery addr len: 2
[2023-04-19T16:18:46.133521177+00:00 INFO core_network::protocols::discovery] get discovery addr len: 2
< NO MORE LOGS >

axon-node4 logs are identical to axon-node3

Questions

• Could you identify the issue given the logs above? Why the nodes cannot produce new blocks?
• I believe Axon nodes should be able to recover in this scenario, or at least log the obvious issue reasons and suggest a solution to node operators

Contact Details

No response

What happened

I'm testing Axon Kubernetes cluster nodes' upgrade from a quite old version (October 24, 2022) to the latest 1.0.8 release.

Initial version: we have a fork last synced with the main axon repo on October 24. We needed a fork to set gas limit to 50M. Otherwise this version is identical to this revision of the main repo, which is pre-v0.1.0-alpha.1 release (published on December, 12).
All in all, this is a quite old version of Axon.

We're currently running this old version for https://www.axon-node.info/, and our goal was to try upgrade to v0.1.0-alpha.8. I ran the cluster locally using axon-devops fork, where image was set to the old ghcr.io/tvl-labs/axon:0.0.5 (you can use it to reproduce — this is the image built from this revision.

Once the 4 nodes started, all logs looked fine, and blockchain was producing new blocks.

Then I updated to image: axonweb3/axon:v0.1.0-alpha.8 (latest release), and applied:

 kubectl apply -f axon1-statefulset.yaml axon2-statefulset.yaml axon3-statefulset.yaml axon4-statefulset.yaml

Pods' images were updated fine, and 3 out of 4 nodes continued working and had no errors in the log. Blocks are being produced as well.

But, there is 1 node that experiences issues syncing with the chain:

[2023-04-20T11:11:44.847298293+00:00 INFO core_consensus::synchronization] [synchronization]: try syncing block, current_consented_number 663,syncing_number 664
[2023-04-20T11:11:44.850782418+00:00 ERROR core_consensus::synchronization] [synchronization]: commit block 663 error
[2023-04-20T11:11:44.850813209+00:00 ERROR core_consensus::synchronization] [synchronization]: err, current_number 663 err_msg: ProtocolError { kind: Consensus, error: InvalidReceiptsRoot { expect: 0x0000000000000000000000000000000000000000000000000000000000000000, actual: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 } }
[2023-04-20T11:11:44.850832001+00:00 WARN core_consensus::message] sync: receive remote block ProtocolError { kind: Consensus, error: InvalidReceiptsRoot { expect: 0x0000000000000000000000000000000000000000000000000000000000000000, actual: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 } }
[2023-04-20T11:11:44.930098751+00:00 INFO core_consensus::synchronization] [synchronization]: sync start, remote block number 937 current block number 663
[2023-04-20T11:11:44.930209834+00:00 INFO core_consensus::synchronization] [synchronization]: try syncing block, current_consented_number 663,syncing_number 664
[2023-04-20T11:11:44.934313168+00:00 ERROR core_consensus::synchronization] [synchronization]: commit block 663 error
[2023-04-20T11:11:44.934365709+00:00 ERROR core_consensus::synchronization] [synchronization]: err, current_number 663 err_msg: ProtocolError { kind: Consensus, error: InvalidReceiptsRoot { expect: 0x0000000000000000000000000000000000000000000000000000000000000000, actual: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 } }
[2023-04-20T11:11:44.934386001+00:00 WARN core_consensus::message] sync: receive remote block ProtocolError { kind: Consensus, error: InvalidReceiptsRoot { expect: 0x0000000000000000000000000000000000000000000000000000000000000000, actual: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 } }
[2023-04-20T11:11:45.100279334+00:00 INFO core_consensus::synchronization] [synchronization]: sync start, remote block number 937 current block number 663
[2023-04-20T11:11:45.100388793+00:00 INFO core_consensus::synchronization] [synchronization]: try syncing block, current_consented_number 663,syncing_number 664
[2023-04-20T11:11:45.106890585+00:00 ERROR core_consensus::synchronization] [synchronization]: commit block 663 error
[2023-04-20T11:11:45.106983210+00:00 ERROR core_consensus::synchronization] [synchronization]: err, current_number 663 err_msg: ProtocolError { kind: Consensus, error: InvalidReceiptsRoot { expect: 0x0000000000000000000000000000000000000000000000000000000000000000, actual: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 } }
[2023-04-20T11:11:45.107054460+00:00 WARN core_consensus::message] sync: receive remote block ProtocolError { kind: Consensus, error: InvalidReceiptsRoot { expect: 0x0000000000000000000000000000000000000000000000000000000000000000, actual: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 } }
[2023-04-20T11:11:45.601703835+00:00 INFO overlord::state::collection] Overlord: 1 chokes in round 0, voters ["031ddc35212b7fc7ff6685b17d91f77c972535aee5c7ae5684d3e72b986f08834b"]

Looks like that node is stuck on block 663, which was the block at which I ran the upgrade.

Pod restart for that node does not help.

Even though the blocks are being produced, we want to make sure all the nodes can recover after upgrade.

https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/execution-apis/assembled-spec/openrpc.json&uiSchema%5BappBar%5D%5Bui:splitView%5D=false&uiSchema%5BappBar%5D%5Bui:input%5D=false&uiSchema%5BappBar%5D%5Bui:examplesDropdown%5D=false

rpc return:

{
    "jsonrpc": "2.0",
    "result": {
        "type": "0x2",
        "blockNumber": "0x10ea",
        "blockHash": "0x235f3a4750f8ae10edccf0cd42439a3e9f9aa814c16c6f25ee5afd30927e6fd4",
        "hash": "0x05fcc52c5f5b3aaec1c5fd30107530c7aeaaadef83b868ea6e8717da629fae9c",
        "nonce": "0x1",
        "transactionIndex": "0x0",
        "from": "0x82f838aee529ecd1f1b0cd0c92f31c3a5614d2e7",
        "to": "0x5cf83df52a32165a7f392168ac009b168c9e8915",
        "value": "0x1",
        "gasPrice": "0x3",
        "maxFeePerGas": "0x539",
        "maxPriorityFeePerGas": "0x3",
        "raw": "0x02f86405826f690303825208945cf83df52a32165a7f392168ac009b168c9e89150180c080a08273a91220ef946473890f29bee584f8923773371ace0deb19dcbdd4b0ae9707a00e64afd55ed735e03f046c489a0b12992e16bc8b3e03f133e6e275f2df815cb3",
        "input": "0x",
        "publicKey": "0x5735534a583203998c6236e220fb37a13348968e6d1b8157fa552d5c5c079b1b2f055986b66a496c95248f707289e94b7fed7f03c699de537a8b3c63e88cf160",
        "accessList": [],
        "chainId": "0x5",
        "v": "0x0",
        "r": "0x8273a91220ef946473890f29bee584f8923773371ace0deb19dcbdd4b0ae9707",
        "s": "0xe64afd55ed735e03f046c489a0b12992e16bc8b3e03f133e6e275f2df815cb3"
    },
    "id": 1
}

haven't gas field for transcation object

Hey folks! Axon is an EVM compatible app-chain framework built on CKB. We started this project to make Web3 application development quick and easy.

This is the very first Axon Development Updates. Starting here, each of our members will say hello to you in each issue.

So what’s special about Axon?

Some highlights:

• Universal abstraction built on CKB-VM
• Native interoperability based on IBC
• Developer friendly design
• High performance based on Overlord Consensus protocol
• 100% EVM compatibility

Read more: https://docs.axonweb3.io/

Below is the progress we’ve made so far, stay tuned for more updates!

What we have accomplished

• Axon core modules development.
• EVM compatibility debugging. This means the EVM develop tools such as Hardhat and Truffle are completely supported.
• Axon-related DevOps components that include monitor, metrics, APM and so on.
• An all-in-one CLI tool for chain and DevOps management, and here is the tutorial.

What we are doing

• CKB cell visitor mechanism design. As we known, Axon has already embedded a CKB-VM that can load the scripts in CKB cells and verify with the given arguments. Further more, we want Axon take the ability to visit CKB cells, therefore, Axon can verify a live cell in EVM. This extends the EVM execution and signature verification. If you want to participate in the design, here is the discussion #896.
• Token staking, issuing, and election mechanism of PoS. The aim of Axon is an App-Chain framework, so the programmable of staking, issue and election is necessary. Here is the discussion #898.
• Other-can-pay gas mechanism. This is a common demand by many application developers. We enumerate some mature strategy and design axon suitable formulation here #899.

• GitHub: https://github.com/axonweb3
• Docsite: https://docs.axonweb3.io/
• Twitter: https://twitter.com/AxonWeb3

What happened:

Request:

{
	"jsonrpc":"2.0",
	"method":"eth_getBlockByNumber",
	"params":[
		"0x0", 
		false
	],
	"id":1
}

returns block with "nonce": "0x0".

This is crashing graph-node events indexer because it expects 8 bytes of hex-encoded data.

What you expected to happen:

Nonce should be 8 bytes data:
"nonce": "0x0000000000000000"

According to Ethereum JSON RPC specification nonce should be 8 bytes: "nonce: DATA, 8 Bytes - hash of the generated proof-of-work. null when its pending block."

Source: https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbyhash

Additional information:

I think Axon doesn't pad hex values length to what Ethereum spec uses. eg. Axon returns nonce: 0x0 instead of Rinkeby nonce: "nonce": "0x0000000000000000" for Genesis block.

Axon genesis block:

{
    "jsonrpc": "2.0",
    "result": {
        "hash": "0x8ba3f664e40093323344a7a97a3705fc9948a440ed9d5ba10ad49d9cb9ccbdf0",
        "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "sha3Uncles": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "author": "0x0000000000000000000000000000000000000000",
        "miner": "0x0000000000000000000000000000000000000000",
        "stateRoot": "0x3afda6598cfc84363c343f4cf1ab7e65fdac504e38d0b3bddeab2c57158df9fc",
        "transactionsRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "receiptsRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "number": "0x0",
        "gasUsed": "0x0",
        "gasLimit": "0x0",
        "extraData": "0x",
        "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
        "timestamp": "0x61b828ca",
        "difficulty": "0x0",
        "totalDifficulty": null,
        "sealFields": [],
        "baseFeePerGas": "0x539",
        "uncles": [],
        "transactions": [
            "0xb517d9e01b5bebe8bf4bae42224635bb0926aadf520557a4636cd77e8ca1d36b",
            "0xfeee53ae26a79f83037a81f17125f413a516882591da36c6306988043d26d803",
            "0x7754489ee8b55755cf2624e0e1b5b5c671b95d9581932a6404cb177f985e4e38",
            "0x5b524e9de399d0095f3d7fe4b6953e18b25a4fe073b40d9f724d9f101a808fd0"
        ],
        "size": "0x220",
        "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "nonce": "0x0"
    },
    "id": 1
}

Rinkeby genesis block:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "difficulty": "0x2",
        "extraData": "0xd783010600846765746887676f312e372e33856c696e7578000000000000000004ff37b6cf0d06c59dc22ae2084dcd97d400d913ac93506bf6bb9aeec2d2783649c74b1b2c809ba20174b73743dc2eb2b90ebf334786cba6983a3500422f9da701",
        "gasLimit": "0x47e7c4",
        "gasUsed": "0x0",
        "hash": "0x64c7de1f16e1af1a4df968340083b68e029907337ecb24dda695e4852fae9994",
        "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
        "miner": "0x0000000000000000000000000000000000000000",
        "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "nonce": "0x0000000000000000",
        "number": "0x1b4",
        "parentHash": "0xef085723d86c56bd702e078308895e5c1131e7146377d2d492f5644fb467cda6",
        "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
        "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
        "size": "0x260",
        "stateRoot": "0x9853b6c62bd454466f4843b73e2f0bdd655a4e754c259d6cc0ad4e580d788f43",
        "timestamp": "0x58ee5f58",
        "totalDifficulty": "0x342",
        "transactions": [],
        "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
        "uncles": []
    }
}

Sunset of San Francisco taken from the Grizzly Peak.

What we have accomplished

Several configuration fixes and dependency version upgrades got completed in the last three weeks!

🥳 Axon now supports rpc calls to get block and proof by block ID! ‣

👌🏻 We’ve finished the initial development of several modules for Axon Spark, the kicker for Axon.

• Storage module has been developed and merged axonweb3/spark#8. It includes both the smt and sqlite to store the staking information.
  • smt: stores staker, delegator, reward and proposal information of all epochs for axon chain.
  • sqlite: stores all axon staking, delegating, withdrawing transaction history. It is worth notice that the transactions happen on CKB.
• Query module has been developed and merged axonweb3/spark#10. It defines the query APIs that handle the requests from the frontend.
• Staking transaction structure has been constructed axonweb3/spark#9. It puts together the data required to construct the staking transaction.

🧑‍🎨 On the frontend side, we’ve closed several rounds of UI design.

What we are doing?

• Intensively developing all kinds of transactions and related contracts for staking, delegating, and withdrawing.

• Finalizing our website design and development.

• Then we will be conducting integrated tests and preparing for the release afterwards!

Stay tuned!

Sometimes you go out for coffee not for the coffee (although they have the best Hambella in town), but for other species. 🐈

If you've read the last update #900, you should know that Axon has done most of the base module development and EVM compatibility debugging.

At this stage, our main focus is on interoperability and the abstraction of the economic model.

What we have accomplished

• We have finalized the design of the cell visitor. #896 presents our current solution that grants Axon to access cells in CKB. It is a modular solution and can reuse the existing infrastructure in the CKB ecosystem.
• #899 describes the design of gassless transactions, a highly requested feature which is mainly about sending transactions and interacting with dApps without paying gas fees by the user. We put forward a system contract to handle such transactions to reduce any difficulty of adaptation for developers.

What we are doing

• To enable better development of system contracts, we have refactored the interface in executor module #901.
• The implementation of the design described in #896 consists of three parts, where the following two have the highest priority:
  • The image cell system contract (ICSC) is the storage module of CKB cells and block headers. Although it is a system contract, the interface is generated by Solidity. Besides, other features of ICSC are also under development here #917. We are open to any suggestions and questions. Feel free to create a pull request!
  • Cell emitter is an indexer-like component, which needs to index a specific cell and interact with ICSC through a relayer. The code is here.
• The staking mechanism design is still in progress, and the assignee is developing the POC in #898.
• We are redesigning Axon’s logo and we’d like to know what you think #923.

Contact us to learn more:

• Mail
• GitHub
• Docsite
• Twitter
• Medium

The Longjing village, Hangzhou, China

What we have accomplished

• In the previous period, Axon makes some breaking changes include:
  • Now support pre EIP-155! Chain ID is no longer essential. #111
  • More concise and streamlined config files after #1162! ✨ As we changed the initial distribution from mnemonic to address and removed many useless fields in config file.
  • Since the Axon is closing to the initial release version, we add #1166 to start.
  • We refactor the block header #1152, and after this the primitive structure will be stable.
• Hi, our future stakers and delegators, we’re now actively staking related programs! Let us know if you have any questions.
• Can I hardfork my blockchain built on Axon? 🤔 Sure! As a highly customizable app-chain framework, Axon is working on an upgrading mechanism specifically prepared for future hardforks. Details will be revealed soon. Stay tuned!

What we are doing?

Answer is: INITIAL RELEASE!
The whole team has been working on it, putting in extra effort to develop and debug our staking-related contracts, ensuring they meet our high standards.

But that's not all! We are also moving towards finalizing the cross-chain mechanism with CKB, which is crucial for Axon's functionality. Now we’re debugging and smoothing out kinks for seamless operation and cross-chain interactions!

Let’s looking forward to the initial release together.

What happened

Hi there! Time for another recap and let’s first have a quick glimpse of what we've done in the last two weeks:

• Upgraded the metadata contract to a new system contract, thanks to the contribution from #1038.
• Added four Ethereum APIs in #1045 that are related to uncle block. Because Axon uses Overlord consensus and there is no uncle block, these interfaces return null or 0.
• Added a new dummy input mode of cell verification in #1044. Cells can thus be simulated for verification in case there is no cell on CKB.
• Fixed a compile failure issue on Arch in #1064.

And, as always, a quick update on what we're working on:

• Adding a new working mode to the Emitter: WebSocket for public services.
• Writing a system contract to maintain CKB light client on Axon, to verify cross-chain messages.

Stay tuned for more and let's keep building!

Contact Details

No response

Propose-a-new-feature

Now that node_X.toml files contain only one secret privkey (there used to be also mnemonic and cross_client.pk but you have removed them), it becomes reasonable to move privkey from the toml file to an ENV variable.

We run Axon nodes in EKS cluster and use CSI Driver to mount secrets from AWS Secrets Manager into the pod.

Alternatives you've considered

Describe alternatives you've considered:

Even more robust solution would be to support the remote AWS signer (#1136), but it is unfeasible right now because AWS KMS does not support BLS cryptography.

Anything else?

No response

Contact Details

No response

Propose-a-new-feature

Summary

In EIPs, it said:

• EIP-2930 requires EIP-2718, EIP-2929.
• EIP-1559 requires EIP-2718, EIP-2930.

Axon transactions support EIP-2930 and EIP-1559:

But Axon receipts not support EIP-2718.

Details

According to EIP-2718:

Receipt is either TransactionType || ReceiptPayload or LegacyReceipt.
... ...
LegacyReceipt is kept to be RLP encoded bytes; it is rlp([status, cumulativeGasUsed, logsBloom, logs]).
... ...
ReceiptPayload is an opaque byte array whose interpretation is dependent on the TransactionType and defined in future EIPs.

As EIP-2930 defined: if TransactionType is 1, ReceiptPayload is rlp([status, cumulativeGasUsed, logsBloom, logs]).

As EIP-1559 defined: if TransactionType is 2, ReceiptPayload is rlp([status, cumulative_transaction_gas_used, logs_bloom, logs]).

Alternatives you've considered

No response

Anything else?

It's almost impossible to verify a Axon receipt with receipts root:

• Axon receipts not support EIP-2718.
• Without EIP-2718, the RLP-serialised LegacyReceipt also is incorrect (ref: #1259).
• Even users use the Axon-specific RLP-serialised of receipts, the receipts_root is still could be verified since the incorrect LegacyReceipt is not used when calculates receipts_root (ref: #1258).

Contact Details

No response

Propose-a-new-feature

Describe the solution you'd like:

In addition to the linux/amd64 images published to https://hub.docker.com/r/axonweb3/axon/tags

developers working on M1 chip will be happy if you also build and publish linux/arm64

We're running Axon nodes locally for testing and development, and we have to build the images locally with cargo build, but it takes significant time (>10m on my machine) and requires patching of axon-devops

Alternatives you've considered

Describe alternatives you've considered:

Anything else?

No response

Current Behavior

1. Send eth_call request with blockHash argument from EIP1898

curl --location 'https://testnet.khalani.network/' \
--header 'Content-Type: application/json' \
--data '{
    "method": "eth_call",
    "params": [
        {
            "gas": "0x2faf080",
            "from": "0xeb4bd0b958136d9979f4fe3187293ab85f9f8c39",
            "to": "0x50309b2b1e9cec265fa76b0c15e1b2a1fb9df1e7",
            "data": "0xf5e3c46200000000000000000000000016948b579240a89d306901dc7d91ad2dbc058fd4000000000000000000000000000000000000000000000000000000000080237b0000000000000000000000008b4651f615d141491381dc8f1345f45f6a8e7536"
        },
        { "blockHash": "0x24d0ffa278f465cd4e2abfb1c8f3b675aa6d2123ecf5278b08e8dc7c5a118492" }
    ],
    "jsonrpc": "2.0",
    "id": 8
}'

Error is received:

{
    "jsonrpc": "2.0",
    "error": {
        "code": -32602,
        "message": "Invalid block hash: 24d0ffa278f465cd4e2abfb1c8f3b675aa6d2123ecf5278b08e8dc7c5a118492 at line 2 column 91"
    },
    "id": 8
}

Block hash is valid block hash from Axon RPC getBlockByNumber:

Expected Behavior

Expected Behavior:

1. Send eth_call request with blockHash argument from EIP1898
2. Response is received, no errors

Working example from Sepolia:

curl --location 'https://rpc.sepolia.org' \
--header 'Content-Type: application/json' \
--data '{
    "method": "eth_call",
    "params": [
        {
            "gas": "0x2faf080",
            "from": "0xeb4bd0b958136d9979f4fe3187293ab85f9f8c39",
            "to": "0x50309b2b1e9cec265fa76b0c15e1b2a1fb9df1e7",
            "data": "0xf5e3c46200000000000000000000000016948b579240a89d306901dc7d91ad2dbc058fd4000000000000000000000000000000000000000000000000000000000080237b0000000000000000000000008b4651f615d141491381dc8f1345f45f6a8e7536"
        },
        { "blockHash": "0x7e3c5599d8d8cc9adca56aa94a9c75fa7f89ad5c0c4fa29f847245571bde0025" }
    ],
    "jsonrpc": "2.0",
    "id": 8
}'

Axon version

v0.1.0-beta.1

On a summer evening, there was a beautiful sunset downstairs of my house when I went for a walk.

(📸 Photo taken in my hometown)

What we’ve done in the past two weeks:

• Completed a system contract to maintain CKB light client on Axon, which enhances the level of security for cross-chain messages verification but lower computational costs. It is a fundamental component that provides convenience for cross-chain solutions #1068

• Removed block header from the ICSC (image cell system contract), because it was deemed unnecessary #1066

• Allowed ICSC to receive multiple blocks, thereby improving system performance #1069

• Fixed bugs related to cell capacity calculation #1074 and interoperable transaction signatures decoding #1092

What we are doing:

• We’re using (after several long discussions 🤪) SMT (Sparse Merkle Tree) data structure to store stake and delegate information for Axon’s staking and election design.
  And if you have any ideas, we’d love to hear them! Come join our discussion Design a new mechanism about stake and election #898!
• Redesigning the genesis block to optimize the project structure.
• Keeping improving Ethereum compatibilities, such as EIP1820 and EIP1898.

Propose-a-new-feature

For Blockscout to properly index internal transaction it seems that "debug_traceTransaction" RPC API is needed. Is this something that is possible to implement in Axon?

Example Blockscout "debug_traceTransaction" call: blockscout/blockscout#7225 (comment)

The doc https://github.com/axonweb3/axon/blob/1f346175f773433f69082b03e247e2fb85acd00a/devtools/chain/README.md is outdated.

Wuyi Mountain is truly a nature lover's paradise. The rolling verdant hills and majestic peaks are a sight to behold. The streams, waterfalls and hot springs are serene and picturesque.

(📸 Photo taken during my recent Wuyi Mountain trip)

What we have accomplished

• We have abstracted the CKB built-in type id contract as the library ckb-type-id that lets developers embed the validation logic of type id in their own contracts. We tested it out and found that it consumes fewer cycles! ✌️
• We have replaced some implementations of RLP with RLP proc-macro #1031. It's working great so far.
• We have finished the research on the integration of ERC-20 gas payments and we will be sharing our design document soon!

And a quick update on what we're up to:

• For the staking and election design for Axon, we are still discussing some issues, such as:

  • using the claim pattern to decouple the validator accounting and rewarding
  • solving L2 liveness problems in a decentralized manner through L1 governance, rather than relying on a L2 “admin”.

  Join our discussion in #898!

• We are researching the integration with the Ethereum 2.0 light client. It is still in its early stages and will be shared on the Github discussion when any progress has been made.

The beauty of Nai Harn Beach. Picture taken in Thailand, 2021.

Hi folks, here's a summary of our recent accomplishments and ongoing work:

What we have accomplished

• Optimized the transaction signature quantities specification in JSON #1241.
• The kicker of Axon, Spark, has finished some important updates:
  • Developed and merged Tx-builder module, an important part of the staking mechanism. You can find the details in the following pull requests:
    • axonweb3/spark#20
    • axonweb3/spark#21
    • axonweb3/spark#22
  • Added transaction testing tools axonweb3/spark#23 to enhance our development efficiency.

What we are doing

• Our focus remains on improving staking-related transactions.
• Refactoring axon-cli, and one of the process PR axonweb3/axon-cli#18 is currently under review. We welcome any input and value your feedback!

Stay tuned for more exciting updates and progress of Axon!

The grace of dolphin comes from within. I will return and find you again.

Photo taken in Mauritius 📍🇲🇺

What we have accomplished

• We’ve added the feature of validating CKB image cells using ckb-vm in Axon after a few weeks’ work, as described in #896. Secp256k1 is no longer the only signature algorithm to verify Axon transactions; other algorithms and more complex logic will be available.

  The entire validation takes place within the ckb-vm and the program used is stored in ICSC (Image Cell System Contract), combining the power of CKB’s abstract capabilities with Axon. Axon supports two methods to run a script in ckb-vm:

  • call_ckb_vm(): Load the script binary from ICSC and run in ckb-vm directly.
  • verify_by_ckb_vm(): Mock a CKB transaction according to the given info and verify it in ckb-vm.

  A temporary deployment script is also provided here, so you can try out this feature immediately.

What we are doing

• The staking and election design for Axon is undergoing updates with the latest design protocol here. For improved security and fairness, we’ve agreed that more operations should be conducted on CKB. How to deal with inactive validators is another concern of our investigation. Join our discussion in #898
• We are researching the integration of ERC20 gas payment and the integration with the Ethereum 2.0 light client. This research is still in its early stages and will be shared on the Github discussion when any progress has been made.

The sunset is setting, the breeze is coming, the lake is sparkling, reflecting the sunset.

Photo taken in Zhejiang, China.

✅ Tasks done in the last 2 weeks

• Finished the design of staking, delegation, reward and election. We're ready to start developing it!

• New features implemented!

  Added compatibility with [EIP-1898], #1101
  Removed modexp limit for executor #1119

• Also been doing refactoring to make everything run more smoothly:

  Increased the maximum RPC gas cap limit #1133
  Changed metadata contract from solidity to system contract #1115
  Changed the bound of ExecutorAdapter trait #1112
  Updated logo #1103

• Bugs fixed:
  Conflict test db path #1109
  Bugs related to interoperability signature verification #1105

🏃‍♂️ What we're up to:

• Designing kicker’s architecture. Kicker plays an important role in any Axon-based chain, responsible for tasks such as submitting Axon checkpoint to CKB, updating metadata cell. (Hey, if you’re not familiar with these terms yet, check [Axon Fundamentals]
• Designing the UX of Staking. The wireframe has been well drafted and we are keep refining it. ✨
• Keeping up with Ethereum and implementing [EIP-1820].

What happened:

net_version returns "0x5" (a hex string instead of number as a string type)

https://github.com/axonweb3/axon/blob/03e13289339187f31c1839d21cc5d9d9636a95d1/tests/e2e/src/net_version.test.js

What you expected to happen:

net_version returns "5"

like in specification: https://ethereum.org/en/developers/docs/apis/json-rpc/#net_version

How to reproduce it (as minimally and precisely as possible):

call net_version on Axon

Anything else we need to know?:

There was similar issue opened in the past for Godwoken: godwokenrises/godwoken-web3#424

This is for example breaking blockscout compatibility with Axon. Some stuff in UI isn't working with errors:

blockscan  | 2023-01-06T12:56:31.386 [error] #PID<0.6038.1> running BlockScoutWeb.Endpoint (connection #PID<0.6036.1>, stream id 1) terminated
blockscan  | Server: axon-explorer.digipnyx.org:80 (http)
blockscan  | Request: GET /smart-contracts?hash=0x8591393d30a2290e81aba2de4d9032cca1ee8ff4&type=regular&action=write
blockscan  | ** (exit) an exception was raised:
blockscan  |     ** (ArgumentError) errors were found at the given arguments:
blockscan  |
blockscan  |   * 1st argument: not a textual representation of an integer
blockscan  |
blockscan  |         :erlang.binary_to_integer("0x271c")
blockscan  |         (ethereum_jsonrpc 0.1.0) lib/ethereum_jsonrpc.ex:269: EthereumJSONRPC.fetch_net_version/1
blockscan  |         (explorer 0.0.1) lib/explorer/chain/cache/net_version.ex:13: Explorer.Chain.Cache.NetVersion.handle_fallback/1
blockscan  |         (explorer 0.0.1) lib/explorer/chain/cache/net_version.ex:8: Explorer.Chain.Cache.NetVersion.get/1
blockscan  |         (block_scout_web 0.0.1) lib/block_scout_web/templates/smart_contract/_functions.html.eex:69: anonymous fn/3 in BlockScoutWeb.SmartContractView."_functions.html"/1
blockscan  |         (elixir 1.13.1) lib/enum.ex:2396: Enum."-reduce/3-lists^foldl/2-0-"/3
blockscan  |         (block_scout_web 0.0.1) lib/block_scout_web/templates/smart_contract/_functions.html.eex:35: BlockScoutWeb.SmartContractView."_functions.html"/1
blockscan  |         (phoenix 1.5.13) lib/phoenix/view.ex:472: Phoenix.View.render_to_iodata/3

Contact Details

No response

Current Behavior

This issue is associated with #1274; in #1274, I said the states of the same genesis block are different.

There is another issue: the genesis state is changed, why the executable binary still can run normally?

There are two different scenes:

• Like #1274, the genesis is same but genesis state is changed.

• Users update their genesis.json or use an incorrect genesis.json to run the chain.

  How to reproduce:

  • Run a dev chain.
  • Edit your genesis.json as you like.
  • Run the dev chain again.
  • The chain runs normally even the genesis is changed.

Expected Behavior

The executable binary should be panicked when the genesis state is changed.

OS

Not Associated

Axon version

v0.1.0-beta.x

Kernel

Not Associated

Relevant log output

No response

Anything else?

It should avoid changing the states, and have checks on that to make sure that any break change could be found before a new commit merged. (ref: I said in #1274)

And also, what I want to say in this issue is, that the executable binaries should do some checks in runtime and throw exceptions when the genesis state was changed.

Contact Details

No response

What happened

Describe the problem details:

The current axon kubernetes configurations deploy 4 nodes , which we do not believe would uphold BFT guarantees. In order to alleviate this , we are planning to add an additional node.

While examining the node.toml, I am trying to understand how you precompute this value, as I cannot find any generators similar to the genesis one to create this.

My purrfect gym partner is yawning!

What we’ve done in the last two weeks

🥳 Beta 1 Release

Hey, have you noticed our new badge? Axon Beta 1 was released on 24th May!

In the latest version:

• RPC methods axon_getMetadata and axon_getCkbRelatedInfo were added. #1188
• Privkey can be fetched from env, instead of from the .toml file to an env variable. #1192

Besides that, random generation of filter IDs ensures their untouchable nature, preventing uninstallation by other users, while also enabling sticky load balancing of filter requests. #1203

✨ Spark is Growing Strong

You recall Spark, the kicker of Axon? It’s permissionless and plays a key role telling Axon where to locate the latest metadata cell in CKB, and relaying the latest checkpoint from Axon to CKB. Besides, Spark updates Axon's metadata through subscribing the checkpoint cell in CKB, and unlocks rewards by updating the reward cell.

Ever since Spark gained the ability to communicate with CKB via RPC requests to ckb_indexer(axonweb3/spark#12), it has experienced quite a few exciting first-time moments! 🍻

Spark has:

• Enabled the function of creating omni-lock, a new lock script that powers interoperability axonweb3/spark#14
• Minted the first xUDT (Extensible User Defined Tokens) axonweb3/spark#15 and built the first stake transaction axonweb3/spark#16 on CKB’s testnet!

And we're close to the finish line with the static pages of Spark UI.

🌟 Refractors

We’ve been polishing our code — constantly. Several refactors have been made on:

CKB light client system contract ABI and the output encode of get_cell and get_header in precompile contracts.

What’s on the way

• We‘ll be working on Spark, including debugging and updating the checkpoint, metadata tx, delegate tx, and the node.js part of UI
• We’ll update axon-cli to be compatible with the latest Axon version.

Contact Details

No response

Propose-a-new-feature

Describe the solution you'd like:

This Ethereum EIP https://eips.ethereum.org/EIPS/eip-1898 provides more guarantees to indexers (https://thegraph.com/en/) because they can specify the exact block for which to query blockchain state using eth_call.

Currently, The Graph has a workaround for non EIP-1898 compatible chains:
https://github.com/graphprotocol/graph-node/blob/7f67bb8836241c4304d5f8c098e39d2eb3708743/chain/ethereum/src/ethereum_adapter.rs#L432

where it uses block number instead of block hash for requests. But it might lead to inconsistent indexing results, if there is a chain reorg happening while the graph is indexing. Probably The Graph is able to detect reorgs later but I can only guess what is the reliability of this.

It would be great if the eth_call and other defaultBlock aware methods would parse the block by blockHash and return blockchain state at the time of the specific block.

Alternatives you've considered

No response

Anything else?

No response

Recently on an art exhibition I found this impressive installation. A complex terrain of darkness and brightness eventually leads to a sudden white light.

What we have accomplished

• Solidity contract of gasless mechanism #960. The pull request is in review, and we are open to your comments!
• Cell emitter, except the RPC communication with the IBC relayer. The code is in this repo and here is the design.

What we are doing

• Two custom precompile contracts:

  1. To get a CKB cell by outpoint
  2. To verify CKB cells through a mock transaction

  These contracts are used to read and verify cells in CKB. Here is the specific design ideas #896

• The logic of the transaction pool affected by the gasless fee.

• The discussion of election, staking and issuing is still in progress. Check out the discussion here #898

Contact us to learn more:

• Mail: [[email protected]](mailto:[email protected])
• GitHub: https://github.com/axonweb3
• Docsite: https://docs.axonweb3.io/
• Twitter: https://twitter.com/AxonWeb3
• Medium: https://medium.com/@axon_web3

Contact Details

No response

Current Behavior

Summary

If "Axon is compatible with Ethereum" as that written in the README.md, the RLP implementation of receipt is incorrect.

Details

Here is the RLP implementation of receipt in Axon:

Yes, in legacy Ethereu JSON-RPC Specification (a.k.a. Ethereum Execution API Specification now), a receipt will have more that 10 fields.

But when do RLP of a receipt, only 4 fields should be used, that was written in section 4.3.1 of Ethereum Yellow Paper since the day when Ethereum launched.

... ... the status code of the transaction, $R_{z}$, the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $R_{u}$, the set of logs created through execution of the transaction, $R_{l}$, and the Bloom filter composed from information in those logs, $R_{b}$:

... ...

The function $L_{R}$ prepares a transaction receipt for being transformed into an RLP-serialised byte array:

$$L_{R}(R) = (R_{z},R_{u},R_{b},R_{l})$$

Also, you could NOT restore a JSON-RPC receipt from a RLP-serialised receipt.

Expected Behavior

None.

OS

Not Associated

Axon version

No response

Kernel

Not Associated

Relevant log output

No response

Anything else?

No response