New network request - Hedera

[mshakeg]

Network information

• Name: Hedera(testnet & mainnet)

• ChainId:
  testnet: 296
  mainnet: 295

• RPC http/s address:
  testnet: https://testnet.hashio.io/api
  mainnet: https://mainnet.hashio.io/api

• Link to https://chainlist.org/
  testnet: https://chainlist.org/chain/296
  mainnet: https://chainlist.org/chain/295

• Blockexplorer:
  testnet: https://hashscan.io/testnet/
  mainnet: https://hashscan.io/mainnet/

[Uxio0]

Did you deploy the contract?

[mshakeg]

@Uxio0 no not yet, will try to this weekend.

[Uxio0]

We changed the steps for getting the deployment, please:

• I have run RPC='http://my-rpc-address' yarn estimate
• I have sent requiredFunds to 0xE1CB04A0fA36DdD16a06ea828007E35e1a3cBC37

And then let us know

[Uxio0]

@mshakeg can you send funds to 0xE1CB04A0fA36DdD16a06ea828007E35e1a3cBC37 and I will deploy it for you?

[mshakeg]

@Uxio0 appreciate it, been really busy. I just sent some HBAR to that account on the Hedera testnet and mainnet.

Can you please transfer any excess to any of the deployed contracts? Hedera charges contract rent so this excess balance will allow for the contract to pay rent and persist on the network.

[Uxio0]

Sorry, account is only used for deployment and we will not do any refund or perform any more actions than deploy the contracts. There are a lot of networks we need to support and we cannot do custom steps for some of them.

Contract was deployed in both networks

[mshakeg]

@Uxio0 I don't see any contract deployed at 0x914d7fec6aac8cd542e72bca78b30650d45643d7?

So I tried to deploy it but it failed:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0xf8a88086019c1c38a400830149f88080b853604580600e600039806000f350fe7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf3820273a0643f821328556c0a64ceb550b926d1c35eb38285086042f1856b018e2696d8b2a052291d2b40968efc09c3e395d9e1c9e34437a1502be6031437fe0ba2d100baa9"],"id":1}' -H "Content-Type: application/json" https://testnet.hashio.io/api

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": 32001,
    "name": "Nonce too low",
    "message": "[Request ID: 998bbfd7-91ef-41bc-8cd7-a262237971a7] Nonce too low. Provided nonce: 0, current nonce: 0"
  }
}

[Uxio0]

@mshakeg I don't know what to say, I got a success message with a tx-hash. Something looks off in your network, how can you get a "Nonce too low" if the current nonce is 0?

[mshakeg]

@Uxio0 I agree, just wanted another confirmation before I created a bug report for Hedera

[mshakeg]

Hi @Uxio0 can you please resign the transactions for both testnet and mainnet again but at a higher gas price say 2200000000000 as the gas price has since increased to 1870000000000

[Uxio0]

Sorry, I have already deployed the contract on both networks, even if it seems to be a problem on mainnet, I'm not spending more time in the network unless you clarify what's going on

[mshakeg]

@Uxio0 I don't think the contract was actually deployed on either testnet or mainnet. It seems like there's an intermittent bug on the Hedera JSON RPC Relay causing a nonce issue, the Hedera team would like to debug further, can you at least re-sign the transaction for testnet?

Also I can confirm that your transaction did not go through as the account still has a nonce of 0

curl -X POST \
  https://testnet.hashio.io/api \
  -H 'Content-Type: application/json' \
  -d '{
  "jsonrpc":"2.0",
  "id":1,
  "method":"eth_getTransactionCount",
  "params":["0xE1CB04A0fA36DdD16a06ea828007E35e1a3cBC37", "latest"]
}'

Response:

{
  "result": "0x0",
  "jsonrpc": "2.0",
  "id": 1
}

[Uxio0]

Again:

{"jsonrpc":"2.0","id":44,"error":{"code":32001,"name":"Nonce too low","message":"[Request ID: 456829e1-91b8-4e39-946b-f6b1589adaa7] Nonce too low. Provided nonce: 0, current nonce: 0"}}

[mshakeg]

@Uxio0 thanks, assuming this is a newly signed transaction with a higher gas price, can you provide the transaction data so the Hedera team can debug further?

[Uxio0]

Yes, it was a new transaction, but I won't prepare a tx again, sorry. Hedera team should be able to debug it with the original transaction I have provided already even if gas price is higher

[mshakeg]

@Uxio0 that's fine, but can you at least share this new transaction so that once they resolve the issue the transaction can actually be submitted, as the old transaction gas price is now too low.

[mshakeg]

Hello @Uxio0 and @mmv08

Could you please re-sign the transaction for both the Hedera testnet and mainnet(which should use a nonce of 1)? The initial transaction(which had a nonce of 0) failed due to an issue with Hedera. As detailed in this comment, Hedera will not reset the nonce for the safe deployer to 0 which would allow for the initial transaction to be replayed.

[Nana-EC]

Hello @Uxio0 and @mmv08

Could you please re-sign the transaction for both the Hedera testnet and mainnet(which should use a nonce of 1)? The initial transaction(which had a nonce of 0) failed due to an issue with Hedera. As detailed in this comment, Hedera will not reset the nonce for the safe deployer to 0 which would allow for the initial transaction to be replayed.

@Uxio0 and @mmv08
We're working on a solution on the Hedera side in which you'll be able to fix the account using your own keys and restore a nonce of 0.

I can circle back once I've confirmed this with the steps needed to unblock this flow and attempt a contract creation then.

[mmv08]

Could you please re-sign the transaction for both the Hedera testnet and mainnet(which should use a nonce of 1)?

This is obsolete because the factory address depends on the deployer account's nonce. If the transaction with nonce 0 failed then the chance to deploy the factory is burned.

[mshakeg]

@mmv08 that shouldn't be an issue based on what @Nana-EC said, there'll be a way for the safe deployer to reset its nonce back to 0 which would allow the initial tx to be replayed.

[Uxio0]

When nonce is reset please open an issue again and let us know

[mshakeg]

I've deployed my own safe deployment in case anyone wants to deploy safes until the canonical deployment is live:

mshakeg/safe-deployments#1

[mshakeg]

PLEASE IGNORE THIS COMMENT UNTIL THE HEDERA MAINNET RELEASE 0.48 AS PER COMMENT

@Uxio0 Hedera resolved the issue, can you please reset the safe deployer nonce on the singleton deployer account 0xE1CB04A0fA36DdD16a06ea828007E35e1a3cBC37 using the script here

@Nana-EC correct me if I'm wrong, in the above project's .env file OPERATOR_KEY should be set to the ecdsa(evm) private key and OPERATOR_ID should be set to the evm address for the above account i.e. 0.0.3867972

[Nana-EC]

@Uxio0 please hold off on the script.
We want to make sure the fixes on the network are rolled out in both testnet and mainnet and simplify the script for you to avoid any more back and forth.
I'll circle back here with an update where it's right to retry.
Thanks

[Uxio0]

You will need to open a new PR when that's ready

[Nana-EC]

@Uxio0 here's a simple hardhat script that you can run against our network to fix your account - https://github.com/hashgraph/hedera-json-rpc-relay/tree/reset-account-nonce-script/reset-account-nonce-script
After that the initial transaction should be able to be reset.

You could use 0x00000000000000000000000000000000000d77f4 as the RECEIVER_ADDRESS env variable as that's the account that initially funded you. Or any other account you have in mind.

I would advise setting network to previwenet first to test and make sure you're comfortable running.
Then you can try mainnet to actually resolve your issue.
No need to try testnet as that account is fine and the factory contract was successfully deployed

We tried to make it straight forward but let me know if you need assistance here.

You mentioned opening a new PR but i'm not sure what change in your code base you'd be referring to.

FYI @mshakeg

[Nana-EC]

Hey @Uxio0 checking in here.
Script should be pretty simple to run and should unblock the deployment of the contract on the network.
Let me know how it goes thanks

[nlordell]

AFAIU, this would require the deployer PK to sign something that is not a proxy deployment right?

As of right now, this isn't has not been done before for this private key and would require careful internal evaluation of the security implications of this (seeing as the PK is "special" and needed for deterministic deployments of Safe singleton factories).

[Nana-EC]

AFAIU, this would require the deployer PK to sign something that is not a proxy deployment right?

As of right now, this isn't has not been done before for this private key and would require careful internal evaluation of the security implications of this (seeing as the PK is "special" and needed for deterministic deployments of Safe singleton factories).

Thanks @nlordell, you're correct.
Unfortunately because of the error encountered during the original attempt to deploy the contract, the nonce of the Hedera EOA account was incremented even though the contract was not deployed.
The script submits a Hedera non smart contract transaction using the Hedera SDK to delete the EOA account on Hedera and free the accounts EVM address. On Hedera accounts are more than just their EVM address and balance so this is supported.
After this transaction goes through, the EOA address can be refunded and assigned a new Hedera account and the contract deployed using a 0 nonce as expected.
This needs to be done by the PK owners as only they have permissions to alter a Hedera account with that PK.

I agree with the careful evaluation and would expect no less.
The script if very simple and targeted for this exact reason.
@Uxio0 please let me know how I can assist the process here and preferably get a timeline.
We want to unblock the Safe contract being deployed on Hedera and allow users to utilize this in mainnet as right now it's just testnet.

[nlordell]

Unfortunately, we do not want to use the deployer account to sign any messages other than transactions at the moment. One other avenue you can explore is to get the Hedera team to set the contract code at the singleton factory address to the code matching what is on mainnet. I believe there are some other networks that use a similar strategy in order to facilitate the deployment of Safe contracts on the network by default (OP stack does this for example)

[Nana-EC]

Unfortunately, we do not want to use the deployer account to sign any messages other than transactions at the moment. One other avenue you can explore is to get the Hedera team to set the contract code at the singleton factory address to the code matching what is on mainnet. I believe there are some other networks that use a similar strategy in order to facilitate the deployment of Safe contracts on the network by default (OP stack does this for example)

Thanks @nlordell, appreciate the follow up.

That's unfortunate news as we have users looking to use Safe on Hedera mainnet just as they do on Hedera testnet today.
I do understand the considerations here but it would be great if we could explore other options that allow for the factory to be deployed in line with your normal process.
Hedera is an L1 not an L2 like OP.
As such forcing an address location in state that is in the range of valid user addresses to hold contract bytecode that wasn't deployed by users themselves is a tough option.

Notably, it is possible to follow a process similar to what you do today and have you sign a transaction offline that could be submitted to fix your account.
This would be a bit more complex so we didn't go this way first. Could we explore this?

[nlordell]

Yes, we can explore signing regular transactions.

[natanasow]

@nlordell @Uxio0 @mshakeg @Nana-EC

We've got a solution for completely offline and off-chain account deletion transaction signing. Could you explore if that script meets your security compliance?

The usage of the script is pretty simple and it's not related to any third-party required actions, all you have to do is checkout this branch and follow the instructions from README.md (npm install, copy and fill the .env, and run the signing script). Once the script is completed, the signed transaction bytes should be logged in the console (expected execution time is < 100ms). After that, you might provide the signed transaction bytes to us (as a comment in the current discussion) for further transaction execution.

And some tips for your .env configuration:

• From the discussion above I concluded that 0xE1CB04A0fA36DdD16a06ea828007E35e1a3cBC37 is the account we want to reset, exploring it in the hashscan reveals that its id is 3867972

DELETABLE_ACCOUNT_NUM=3867972

---

• Hex encoded 32 bytes (64 length) e.g. 0x0e98be035000000053db957b000000e326e62964ecad8672ad79737050000000

DELETABLE_ACCOUNT_PK=

---

• From the explorer, I've found out this account funded the deletable account and I let it be that, feel free to set an account you want

RECEIVER_ACCOUNT_NUM=882676

---

• Leave it empty

VALID_START_DAYS_OFFSET=

[nlordell]

Unfortunately it isn't exactly clear what we sign with this script. Is this a new transaction type?

[natanasow]

@nlordell It's a hedera-specific transaction.

That's the signing code snippet and here is the official documentation for AccountDeleteTransaction.

[nlordell]

Thanks, is there documentation about the actual raw data that is being signed, and how it is constructed?

[natanasow]

Hedera-specific transactions can be executed only via the SDK, and I'll try to explain what's happening under the hood. You can review the codebase as well.

• AccountDeleteTransaction is defined in the SDK class here - it wraps accountId and transferAccountId
• each hedera-specific transaction inherits this base Transaction
• base Transaction has _signTransaction method that executes _makeSignedTransaction where the encoding is happening based on definitions in protobufs.
• finally, the user signs the encoded protobuf message (e.g. crypto_delete.proto)

Does the explanation above answer your question?

[nlordell]

To give a bit more context, I wanted to understand exactly what the preimage to the hash that is being signed by the private key is. This is important for us to evaluate whether or not signing such a message goes against our internal policy for use of the signer account responsible for deploying the singleton factory contract.

I will need to take a look at what the encoded transaction looks like, but at a first glance, it does not appear to be a "regular EVM transaction". For transparency, this could mean that we can't deploy the singleton factory to the expected address for this network 😞.