findoranetwork / platform Goto Github PK

View Code? Open in Web Editor NEW

72.0 18.0 30.0 44.08 MB

Official Implementation of Findora Network.

Home Page: https://findora.org

License: Other

Shell 2.30% Makefile 0.60% Rust 96.45% JavaScript 0.20% Python 0.21% Solidity 0.24%

platform's Introduction

Findora Platform

Wiki
Change log
Benchmarks
- EVM Benchmarks
- UTXO Benchmarks
- ...

Thanks to all the people who already contributed!

Licensing

The primary license for Platform is the Business Source License 1.1 (BUSL-1.1), see LICENSE.

Exceptions

All files in components/contracts are licensed under Apache-2.0

platform's People

Contributors

Stargazers

Watchers

platform's Issues

When have enough fee for abar transfer, still unable to build and sign the operation

Problem Description

description:

When trying an abar transfer, at the step of build_and_sign I am getting an error, which is apparently caused by non-sufficient fee. But, get_expected_fee method returns 0, meaning no fee needs to be added.

Screenshots:

However, when I am trying to use a very small abar, I do see a handled error, when expected fee amount is > 0

Environmental information

operating system:
MacOS

service:

SDK Triple Masking API

Code version:
SDK - feat_fo_784_abar_to_abar
on this hash

commit a17d91198ea885afba7a4ac9744779353d0e2a01 (HEAD -> feat_fo_784_abar_to_abar)
Author: Oleksandr Kovalov <[email protected]>
Date:   Thu Apr 7 18:52:55 2022 -0400

    feat: fo-784: add fee estimator method to triple masking sdk, refactor abar transfer

platform - develop

on this hash

commit c97e3b8418887e38cf7db640e25dadaebe081606 (HEAD -> develop, origin/develop)
Author: shaitao <[email protected]>
Date:   Wed Apr 6 13:45:38 2022 +0800

    Get more error infomation in config. (#274)

Steps to reproduce

1、prepare 3 abars

that would return 0 as an expected fee

2、run abar transfer

Connection ID Mismatch and Duplicate Connection

Problem Description

description:

There seems to be an ID mismatch between dialed node and actual connection. Jimmy mentioned a possible fix but the issue still persists.

I[2021-10-29|20:21:07.984] Version info                                 module=main software=0.33.9 block=10 p2p=7
I[2021-10-29|20:21:08.010] Starting Node service                        module=main impl=Node
I[2021-10-29|20:21:08.149] Started node                                 module=main nodeInfo="{ProtocolVersion:{P2P:7 Block:10 App:0} DefaultNodeID:eba155315820624eed9ef9850f4586b0012b2cdc ListenAddr:tcp://0.0.0.0:26656 Network:chain-qILMsV Version:0.33.9 Channels:4020212223303800 Moniker:01330fba6f0b Other:{TxIndex:on RPCAddress:tcp://0.0.0.0:26657}}"
E[2021-10-29|20:21:08.558] Stopping peer for error                      module=p2p peer="Peer{MConn{54.149.5.74:26656} 03deb91289c430fecf6883caaf69c69bb66f7d8e out}" err=EOF
E[2021-10-29|20:21:08.619] dialing failed (attempts: 1): duplicate CONN<54.149.5.74:26656> module=pex [email protected]:26656
E[2021-10-29|20:21:08.620] dialing failed (attempts: 1): duplicate CONN<54.149.5.74:26656> module=pex [email protected]:26656
E[2021-10-29|20:21:08.691] dialing failed (attempts: 1): auth failure: conn.ID (03deb91289c430fecf6883caaf69c69bb66f7d8e) dialed ID (66bbf0b1d5824d32e3adc8396a427eb189313a0f) mismatch module=pex [email protected]:26656
E[2021-10-29|20:21:08.713] dialing failed (attempts: 1): duplicate CONN<35.74.251.239:26656> module=pex [email protected]:26656
E[2021-10-29|20:21:08.821] dialing failed (attempts: 1): auth failure: conn.ID (6187e5a11ad97e34a22f6ccdb2a6670f23f94462) dialed ID (5640502c7ad2f53117ffce63276277d4fa081324) mismatch module=pex [email protected]:26656
I[2021-10-29|20:21:09.378] Executed block                               module=state height=1177516 validTxs=0 invalidTxs=0
I[2021-10-29|20:21:09.586] Committed state                              module=state height=1177516 txs=0 appHash=68D3D110D442C67994AC608266AB3AFA8D6810D95D271144C868B33EAF4B731F
E[2021-10-29|20:21:09.589] dialing failed (attempts: 1): dial tcp 16.162.25.134:26656: i/o timeout module=pex [email protected]:26656
I[2021-10-29|20:21:09.968] Executed block                               module=state height=1177517 validTxs=0 invalidTxs=0
I[2021-10-29|20:21:10.198] Committed state                              module=state height=1177517 txs=0 appHash=68D3D110D442C67994AC608266AB3AFA8D6810D95D271144C868B33EAF4B731F
I[2021-10-29|20:21:10.518] Executed block                               module=state height=1177518 validTxs=0 invalidTxs=0
I[2021-10-29|20:21:10.748] Committed state                              module=state height=1177518 txs=0 appHash=68D3D110D442C67994AC608266AB3AFA8D6810D95D271144C868B33EAF4B731F

Environmental information

operating system:
ubuntu 18.04
service:

Code version:
v0.2.8-release

Steps to reproduce

1、Run automated setup script

2、Tail logs

3、

RPC integration tests are failing on testnet

Problem Description

RPC integration tests are failing on testnet https://prod-testnet.prod.findora.org:8545

it might be related to the issue with the CLI (when trying to check balance using cli, it throws an unhandeled error

~/p/Findora  ./fn account -a 0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8                                                       [01:19:10pm]
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: ParseError, message: "Parse error. Invalid JSON", data: Some("expected value at line 1 column 1") }', src/components/finutils/src/common/evm.rs:169:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

so when I am trying to run integration test, it also fails..

console.log
    🚀 ~ rpcParams.rpcUrl https://prod-testnet.prod.findora.org:8545
      at Object.<anonymous> (src/evm/rpc.integration.spec.ts:30:9)

console.log
    🚀 ~ IT IS SENDING file: rpc.spec.ts ~ line 37 ~ payload {
      method: 'eth_sendTransaction',
      params: [
        {
          gas: '0xf4240',
          gasPrice: '0x2540be401',
          from: '0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8',
          to: '0x0a9dfacdeed4f3d433998b6a80ce0a272715e125',
          value: '0x16345785d8a0000'
        }
      ],
      callback: undefined
    }

      at src/evm/rpc.integration.spec.ts:55:15

  console.log
    🚀 ~ IT IS SENT file: rpc.spec.ts ~ line 40 ~ payload {
      method: 'eth_sendTransaction',
      params: [
        {
          gas: '0xf4240',
          gasPrice: '0x2540be401',
          from: '0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8',
          to: '0x0a9dfacdeed4f3d433998b6a80ce0a272715e125',
          value: '0x16345785d8a0000'
        }
      ],
      callback: undefined
    }

      at src/evm/rpc.integration.spec.ts:58:15

  console.error
    Unhandled error

      at process.uncaught (node_modules/jest-jasmine2/build/jasmine/Env.js:248:21)

  console.error
    Error: Transaction check error: 
    # 2021-11-15 18:35:35 [pid: 7] [pidns: 4026532322]
    ERROR: InsufficientBalance, origin: 0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8, actual balance 0, but expected payment 110000000001000000
    |-- file: src/components/contracts/modules/ethereum/src/lib.rs
    |-- line: 189
    `-- column: 24
    

  console.log
    🚀 ~ ERROR file: rpc.spec.ts ~ line 51 ~ error Error: Transaction check error: 
    # 2021-11-15 18:35:35 [pid: 7] [pidns: 4026532322]
    ERROR: InsufficientBalance, origin: 0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8, actual balance 0, but expected payment 110000000001000000
    |-- file: src/components/contracts/modules/ethereum/src/lib.rs
    |-- line: 189
    `-- column: 24

 FAIL  src/evm/rpc.integration.spec.ts (148.399 s)
  Api Endpoint (rpc test) for "https://prod-testnet.prod.findora.org:8545"
    eth_protocolVersion
      ✕ Returns the current ethereum protocol version (356 ms)
    eth_chainId
      ✕ Returns the current chain id (253 ms)
    eth_accounts
      ✕ Returns a list of addresses owned by client (245 ms)
    eth_getBalance
      ✕ Returns the balance of the account of given address (253 ms)
    eth_sendTransaction
      ✕ Creates new message call transaction or a contract creation, if the data field contains code (238 ms)
    eth_call
      ✕ Executes a message immediately without creating a transaction (236 ms)
    eth_coinbase
      ✕ Returns the client coinbase address (239 ms)
    eth_gasPrice
      ✕ Returns the current price per gas in wei (251 ms)
    eth_blockNumber
      ✕ Returns the number of most recent block (247 ms)
    eth_getBlockByHash
      ✕ Returns information about a block by hash (260 ms)
    eth_getBlockByNumber
      ✕ Returns information about a block by block number. (242 ms)
    eth_getTransactionCount
      ✕ Returns the number of transactions SENT from an address (251 ms)
    eth_getBlockTransactionCountByHash
      ✕ Returns the number of transactions in a block from a block matching the given block hash (247 ms)
    eth_getBlockTransactionCountByNumber
      ✕ Returns the number of transactions in a block from a block matching the given block number (237 ms)
    eth_getCode
      ✕ Returns code at a given address (236 ms)
    eth_sendRawTransaction
      ✕ Creates new message call transaction or a contract creation for signed transactions (negative case) (241 ms)
    eth_estimateGas
      ✕ Generates and returns an estimate of how much gas is necessary to allow the transaction to complete (245 ms)
    eth_getTransactionByHash
      ✕ Returns the information about a transaction requested by transaction hash (246 ms)
    eth_getTransactionByBlockHashAndIndex
      ✕ Returns information about a transaction by block hash and transaction index position (248 ms)
    eth_getTransactionByBlockNumberAndIndex
      ✕ Returns information about a transaction by block number and transaction index position (245 ms)
    eth_getTransactionReceipt
      ✕ Returns the receipt of a transaction by transaction hash (251 ms)
    eth_getLogs
      ✕ Returns an array of all logs matching a given filter object (250 ms)

however all works well on forge

  console.log
    🚀 ~ rpcParams.rpcUrl https://prod-forge.prod.findora.org:8545

      at Object.<anonymous> (src/evm/rpc.integration.spec.ts:30:9)

  console.log
    🚀 ~ IT IS SENDING file: rpc.spec.ts ~ line 37 ~ payload {
      method: 'eth_sendTransaction',
      params: [
        {
          gas: '0xf4240',
          gasPrice: '0x2540be401',
          from: '0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8',
          to: '0x0a9dfacdeed4f3d433998b6a80ce0a272715e125',
          value: '0x16345785d8a0000'
        }
      ],
      callback: undefined
    }

      at src/evm/rpc.integration.spec.ts:55:15

  console.log
    🚀 ~ IT IS SENT file: rpc.spec.ts ~ line 40 ~ payload {
      method: 'eth_sendTransaction',
      params: [
        {
          gas: '0xf4240',
          gasPrice: '0x2540be401',
          from: '0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8',
          to: '0x0a9dfacdeed4f3d433998b6a80ce0a272715e125',
          value: '0x16345785d8a0000'
        }
      ],
      callback: undefined
    }

      at src/evm/rpc.integration.spec.ts:58:15

  console.log
    🚀 ~ file: rpc.spec.ts ~ line 44 ~ hash 0xc88853017ca0ae9faf1d9dd7217129cdedb60b38920385edf542f9866da27565

      at src/evm/rpc.integration.spec.ts:61:15

  console.log
    🚀 ~ file: rpc.spec.ts ~ line 45 ~ receipt {
      blockHash: '0x47ec1bc3921391f610fac95fce778f3debf22252054886b563d25cefddf764bc',
      blockNumber: 245815,
      contractAddress: null,
      cumulativeGasUsed: 21000,
      from: '0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8',
      gasUsed: 21000,
      logs: [],
      logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
      status: true,
      to: '0x0a9dfacdeed4f3d433998b6a80ce0a272715e125',
      transactionHash: '0xc88853017ca0ae9faf1d9dd7217129cdedb60b38920385edf542f9866da27565',
      transactionIndex: 0
    }

      at src/evm/rpc.integration.spec.ts:64:15

 PASS  src/evm/rpc.integration.spec.ts (38.679 s)
  Api Endpoint (rpc test) for "https://prod-forge.prod.findora.org:8545"
    eth_protocolVersion
      ✓ Returns the current ethereum protocol version (344 ms)
    eth_chainId
      ✓ Returns the current chain id (244 ms)
    eth_accounts
      ✓ Returns a list of addresses owned by client (245 ms)
    eth_getBalance
      ✓ Returns the balance of the account of given address (402 ms)
    eth_sendTransaction
      ✓ Creates new message call transaction or a contract creation, if the data field contains code (247 ms)
    eth_call
      ✓ Executes a message immediately without creating a transaction (252 ms)
    eth_coinbase
      ✓ Returns the client coinbase address (254 ms)
    eth_gasPrice
      ✓ Returns the current price per gas in wei (259 ms)
    eth_blockNumber
      ✓ Returns the number of most recent block (247 ms)
    eth_getBlockByHash
      ✓ Returns information about a block by hash (248 ms)
    eth_getBlockByNumber
      ✓ Returns information about a block by block number. (253 ms)
    eth_getTransactionCount
      ✓ Returns the number of transactions SENT from an address (240 ms)
    eth_getBlockTransactionCountByHash
      ✓ Returns the number of transactions in a block from a block matching the given block hash (244 ms)
    eth_getBlockTransactionCountByNumber
      ✓ Returns the number of transactions in a block from a block matching the given block number (250 ms)
    eth_getCode
      ✓ Returns code at a given address (242 ms)
    eth_sendRawTransaction
      ✓ Creates new message call transaction or a contract creation for signed transactions (negative case) (263 ms)
    eth_estimateGas
      ✓ Generates and returns an estimate of how much gas is necessary to allow the transaction to complete (262 ms)
    eth_getTransactionByHash
      ✓ Returns the information about a transaction requested by transaction hash (241 ms)
    eth_getTransactionByBlockHashAndIndex
      ✓ Returns information about a transaction by block hash and transaction index position (245 ms)
    eth_getTransactionByBlockNumberAndIndex
      ✓ Returns information about a transaction by block number and transaction index position (242 ms)
    eth_getTransactionReceipt
      ✓ Returns the receipt of a transaction by transaction hash (246 ms)
    eth_getLogs
      ✓ Returns an array of all logs matching a given filter object (270 ms)

Test Suites: 1 passed, 1 total
Tests:       22 passed, 22 total
Snapshots:   0 total
Time:        38.712 s, estimated 149 s
Ran all test suites matching /rpc.integration.spec.ts/i with tests matching "rpc test".

Steps to reproduce

1、
./fn account -a 0x9257e1aeb58e16a9c33e0e8469a1d5205d6350b8
2、
yarn test:emv:integration:rpc:devnet

mocker

Problem Description

description:

Screenshots:

Environmental information

operating system:

service:

Code version:

Steps to reproduce

1、

2、

3、

abci start slow

Problem Description

description:
when the findorad start with data, abci will take a while to start, for testnet 350k height take about 1 min and in mainnet it will take about 5-10 mins.
Screenshots:

Environmental information

operating system:

service:
Findorad
Code version:
v0.3.18-release but this issue start about several version ago I think is around 0.3.16

Steps to reproduce

1、following the wiki page, testnet/mainnet init script start a node with data can reproduce this.

2、

3、

Events in the contract event logs are sorted backwards.

Problem Description

description:

When the contract sends two transfers to two different addresses, the event logs are saved in the wrong order. Earlier event is located later than later event.

Screenshots:

that results in a failing assertion, so instead of seeing a tx hash from the first block , in the first event, we have a tx hash from the later block.

Environmental information

operating system:

n/a running on "https://prod-forge.prod.findora.org:8545"

Steps to reproduce

1、

make sure your eth accounts (which are used to run the test) have enough balance and run yarn test:evm:integration:contract:devnet

txpool should not accept tx with zero gas limit or without limit at all

Problem Description

when sending a transaction with gas equals to 0 or without gas limit at all, the transaction is still being sent successfully:

Screenshots:

Environmental information

possibly related to #140

service:
Findora SDK EVM integration test

Steps to reproduce

1、using sdk run yarn test:evm:integration:contract:devnet (assuming your .env_rpc_dev.json is configured with the proper mnemonic and url

fn failed to get balance of eth account

Problem Description

description:
fn command panicked when querying eth account balance
Screenshots:

Environmental information

operating system:

service:
https://dev-qa02.dev.findora.org
Code version:
Build: testnet-evm-v0.2.6b 2021-11-22

Steps to reproduce

1、

2、

3、

QA02/QA03: Findora Wallet app fails to transfer FRA when “Hide Asset Type” is selected

Problem Description

description:
Findora Wallet app failed to transfer FRA when “Hide Asset Type” is selected

Failed transactions on QA03:
Transaction Hash: F4D2CA0B13070A06CD92FF0A861DD7EED8976EC429AB1BDA418EEA7FDA8FC0AF
Transaction Hash: 7E4949890AF684C15A8C87170A63827397D5297FAAD222C219FD4506A3E791B5
Transaction Hash: 7AE159A6CF6AD0F18365CCF9F76D15A2A28B8747EE79B081EEF5136F59B377D9

Error logs:
https://dev-qa03.dev.findora.org:26657/tx?hash=0x7AE159A6CF6AD0F18365CCF9F76D15A2A28B8747EE79B081EEF5136F59B377D9

Screenshots:

Environmental information

operating system:
MacOS Monterey 12.2.1 (21D62)
service:
Findora Wallet app 0.3.2
Code version:

Steps to reproduce

1、Go to Findora Wallet

2、Go to "Send" tab, fill out the info to transfer FRA from wallet1 to wallet2

3、Select "Hide Asset Type"

4、Click on "Next" and finish the transaction, see transaction fails.

get block by hash sometimes returns NULL

Problem Description

when trying to get data by block hash (i.e. using eth_getTransactionByBlockHashAndIndex or eth_getBlockByHash) returned response is null, even though the transaction has been broadcasted successfully and receipt has been received (so the block is valid as well as its hash).

The problem happens NOT all the time. Sometimes both methods calls return the result (transaction or block), like in the attached video - this time we could get block data but could not get transaction data. Sometimes both methods fail. Sometimes both are passing, which makes it tricky to test and catch the reason.

Screenshots:

CleanShot.2021-11-28.at.20.26.53-converted.mp4

Environmental information

env:
Forge

Steps to reproduce

1、configure your .env_rpc_dev.json and provide proper host url and mnemonic of the account which has EVM FRAfor first 4 addresses

2、run yarn test:emv:integration:rpc:devnet

evm>native transfer error

Problem Description

description:
evm>native transfer error

Screenshots:

Environmental information

operating system:
macos

service:
https://dev-qa02.dev.findora.org

Code version:
Build: testnet-evm-v0.2.6b 2021-11-22

Steps to reproduce

1、evm>native transfer

Some returns of eth_getBlockByNumber may be wrong

Problem Description

description:
There is one block with very strange block info when we use eth_getBlockByNumber

Environmental information

operating system:
N/A
service:
Forge testnet test
Code version:

Steps to reproduce

1、curl -H 'Content-Type: application/json' --data '{"method": "eth_getBlockByNumber", "jsonrpc":"2.0", "params":[135134, false], "id": 1}' https://prod-forge.prod.findora.org:8545 | jq .
We can get the block hash of 135134 is 0x0ef7bb9a32b72756b5d48f001f78e87798406bce5eaea6dbe09d9f6473a272d1 and we get the stateRoot 0x8133cc87d8f9bc17b3e31deac4cd7fb97e6852a2211e4e3b22fbfccd3874b566

2、curl -H 'Content-Type: application/json' --data '{"method": "eth_getBlockByNumber", "jsonrpc":"2.0", "params":[135135, false], "id": 1}' https://prod-forge.prod.findora.org:8545 | jq .
We can find out that the paretHash is 0xac0df09f0699fdaa8af40ce553cd3c03440fc41db47a70ed70e30d86664215f6, which is not match with the previous information.
The stateRoot also changes to 0x1fe00727b579c67555fd07079b36e5b97ce92c2486de6656210f147bf21f3bc3 without any transaction.

3、curl -H 'Content-Type: application/json' --data '{"method": "eth_getBlockByNumber", "jsonrpc":"2.0", "params":[135136, false], "id": 1}' https://prod-forge.prod.findora.org:8545 | jq .
We can see the parent hash matches the hash of previous block again.
The stateRoot changes back to 0x8133cc87d8f9bc17b3e31deac4cd7fb97e6852a2211e4e3b22fbfccd3874b566 without any transaction. This may be a clue.

Local env faucet account is created with 0 FRA balance

Problem Description

After running make devnet to create a local env, the faucet account is ver often created with no balance.

Screenshots:

faucet_is_created_with_no_balance.mp4

Environmental information

operating system:
mac os

Code version:
develop branch on this hash

Steps to reproduce

1、
run make devnet and check all the services are running and returning a response (like rpc, status, version ) also check for ps list for abcid
2、
check the balance - you see 0
3、
run ./tools/devnet/stopnodes.sh to stop the env and then make devnet again. (like repeat step 1) - problem persists.
4、
stop devnet again and remove ~/test/devnet and run cargo update and cargo build and repeat step ` - now it solved (sometimes it requires to repeat step 4 again)..

EVM-test: Fix test-state-root.ts

Problem Description

description:

There is one block delay for the state root hash change. https://www.notion.so/findora/Frontier-Port-8ba31d0819cc4bfd9b5afbacfaa73a30#53df4b3af7a6478a966b20689505e855
We need to confirm whether or not the delay is the correct behavior. We can read frontier source code, check against Ganache or Ethereum network.
We need to fix this delay if it is a bug.
We need to create another task that helps with data migration.

Environmental information

operating system: Any

service: platform

Code version:
main branch

Steps to reproduce

always

Evm>native transaction cannot be found in blockscout

Problem Description

description:
Evm>native transaction cannot be found in blockscout

Screenshots:

Environmental information

operating system:
ubuntu

service:
https://prod-mainnet.prod.findora.org

Code version:
Build: v0.3.5-release 2021-12-14

Steps to reproduce

1、Evm>native transaction

2、Query transaction records

wallet failed staked

Problem Description

description:

use findora wallet , Settings -> Network, select Testnet.
Staking: select fra1g7036rvjcf5y58dc7jgpjsvcv7ymvl7vlpyclcmyrzrz4nrnln8qaw0nmh (balance: 10,000.010000)
stake 10000 amounts, select validator 0856654F7CD4BB0D6CC4409EF4892136C9D24692
tips: failed staked

Screenshots:

Environmental information

operating system:
findora wallet version: 0.1.1

service:

Code version:

Steps to reproduce

1、

2、

3、

Unit test working inconsistently

Problem Description

description:
The unit test txn_builder::tests::axfr_create_verify_unit_positive_tests_with_fees (https://github.com/FindoraNetwork/platform/blob/feat-triple-masking-v3/src/components/finutils/src/txn_builder/mod.rs#L1710) is working when running in the single thread but when 'cargo test' is used and the test is running on multiple threads, it fails.
Screenshots:

Environmental information

operating system:
MAC OS Monterey 12.0.1
service:

Code version:
Branch: feat-triple-masking-v3

Steps to reproduce

1、Run 'cargo test', the test fails.

2、Run 'cargo test txn_builder::tests::axfr_create_verify_unit_positive_tests_with_fees', the test passes.

Triple Masking: Abar to Bar `add_operation_anon_fee` throws an error

Problem Description

When trying to perform abar to bar conversion, at the step of adding anon fee , there is a error being thrown (null pointer being passed to rust)

Screenshots:

Environmental information

operating system:
Mac OS

Code version:
feat_fo_931_abar_to_bar for sdk and feat-triple-masking-v3 for platform

Steps to reproduce

1、
Configure your local env to use triple masking branch and have your account funded from the faucet and some abars being sent to a new anon wallet

2、
please used SDK branch feat_fo_931_abar_to_bar , please note, that abarToBar function in run.ts needs to have your own abar and randomizers info, as well as the wallet info where the abar needs to be sent to and the sender anon wallet info

ie.

  const walletInfo = await Keypair.restoreFromPrivateKey(pkey, password);

  const anonKeysSender = {
    axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
    axfrSecretKey: 'Gsppgb5TA__Lsry9TMe9hBZdn_VOU4FS1oCaHrdLHQCgOiwRkH26riOjFwzrET33dcd1LAGz3TPYMTODtDNK6w==',
    decKey: 'oAOZEUWKbgjv8OVtlL5PJYrNnV1KDtW3PCyZc30SW0Y=',
    encKey: 'eT39SV2et8ONJsN0kCEPJkNQys89UlFUsdPpY2x5qR8=',
  };

  // rnadomizer for abar to be sent
  const givenRandomizerOne = '3PaExNx4SXNnhhE2pVpNiNHpiSXFQThh8qPgUycUDG5G';

  // randomizer to pay fee
  const givenRandomizerTwo = '3NcCcc493iSc2QcTuEGVwSb5vLDHDVpHHEcPPCPUN9Bp';

  const ownedAbarsResponseOne = await TripleMasking.getOwnedAbars(
    anonKeysSender.axfrPublicKey,
    givenRandomizerOne,
  );

3、
run yarn and yarn start.

Triple Masking: Abar to Bar - after processing `Abar to bar` , receiver balance is not changed and Abar is not spent

Problem Description

description:
so the problem is that after calling add_operation_abar_to_bar and processing this operation (so, receiving a new randomizer) the bars are not being spent. so I can still see their balances etc. Also the receiver balance is not being updated (so no new utxo is added to the receiver utxolist).

after running exactly the same operation the second time, I am receiving a new randomizer and a new tx hash but neither balance is changer abar is being spent.

Screenshots:

so first run. at the end we have this randomizer 8MLCqoSD9afdKdCoNyyCXRPxfvyq7oT68UH6RpcSHiGo and this tx hash [start:run] abar to bar result handle!!! 4b08a55e240263e694189a53c217ea1f359f76f486c95066026676952a391548

[start:run] Connecting to "http://127.0.0.1"
[start:run] 🚀 ~ file: run.ts ~ line 1396 ~ abarToBar ~ ownedAbarToUseAsSource {
[start:run]   axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
[start:run]   randomizer: 'DzmNY4BZVUC8rcYWUE55MAuuHFsw314hhpN9uwDX3BiY',
[start:run]   abarData: {
[start:run]     atxoSid: 2,
[start:run]     ownedAbar: {
[start:run]       amount_type_commitment: '7m_3n8o_pnTlLpyvjXrU11_LOmuO8Q1REe4baYCysTg=',
[start:run]       public_key: 'ytYXooOlDUX2ppmSYdFblQb-HiGu0TQ_C6PqY2sHu1E='
[start:run]     }
[start:run]   }
[start:run] }
[start:run] 🚀 ~ file: run.ts ~ line 1407 ~ abarToBar ~ ownedAbarToUseAsFee {
[start:run]   axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
[start:run]   randomizer: 'EECfEi8EPdxLWX2LDMSRdPLwESgtNnQVH3ZrxLtRFz1t',
[start:run]   abarData: {
[start:run]     atxoSid: 1,
[start:run]     ownedAbar: {
[start:run]       amount_type_commitment: 'SFgsqFHnlYEF1OlN8CbI9QxV-gA0lZTrUmJ_1XYJ5Ao=',
[start:run]       public_key: 'v-UquTlv4uIEVsL4uarScI5csl-Fko7EFk61tkl0AeM='
[start:run]     }
[start:run]   }
[start:run] }
[start:run] 🚀 ~ file: tripleMasking.ts ~ line 542 ~ randomizers { randomizers: [ '8MLCqoSD9afdKdCoNyyCXRPxfvyq7oT68UH6RpcSHiGo' ] }
[start:run] 🚀 ~ file: tripleMasking.ts ~ line 547 ~ randomizers { randomizers: [ '8MLCqoSD9afdKdCoNyyCXRPxfvyq7oT68UH6RpcSHiGo' ] }
[start:run] 🚀 ~ file: run.ts ~ line 1413 ~ abarToBar ~ abarToBarData {
[start:run]   anonKeysSender: {
[start:run]     axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
[start:run]     axfrSecretKey: 'Gsppgb5TA__Lsry9TMe9hBZdn_VOU4FS1oCaHrdLHQCgOiwRkH26riOjFwzrET33dcd1LAGz3TPYMTODtDNK6w==',
[start:run]     decKey: 'oAOZEUWKbgjv8OVtlL5PJYrNnV1KDtW3PCyZc30SW0Y=',
[start:run]     encKey: 'eT39SV2et8ONJsN0kCEPJkNQys89UlFUsdPpY2x5qR8='
[start:run]   },
[start:run]   randomizers: [ '8MLCqoSD9afdKdCoNyyCXRPxfvyq7oT68UH6RpcSHiGo' ]
[start:run] }
[start:run] 🚀 ~ file: run.ts ~ line 1413 ~ abarToBar ~ receiverWalletInfo {
[start:run]   keyStore: Uint8Array(188) [
[start:run]     166, 222, 169,  87, 148, 167, 161, 209, 216, 137, 178, 218,
[start:run]     122, 117,  36,   2,   6, 164, 231,  91,  51, 205, 148,  96,
[start:run]      44,  65, 232, 132,  51, 130, 240,  91, 211,  60, 112,   5,
[start:run]     224,  30, 143,  89,  90,  90, 188, 156, 158, 181,  38, 178,
[start:run]     204, 150, 208,  77,  77, 111, 172, 187,  84,  18, 197, 229,
[start:run]     143, 240, 212, 162, 192, 254, 191, 172, 132,  97,   0, 118,
[start:run]     113, 223,   3,  67, 153, 176, 125, 141, 216,  31, 155, 250,
[start:run]      57, 106, 238, 205,  98, 149, 223, 163,  97, 247,  72,  34,
[start:run]      46, 254, 202, 128,
[start:run]     ... 88 more items
[start:run]   ],
[start:run]   publickey: 'NmpU7bLld5JNndmzHozTjpkMBQmA2SAJBlHPumAaNhQ=',
[start:run]   address: 'fra1xe49fmdju4meynvamxe3arxn36vscpgfsrvjqzgx288m5cq6xc2q0ndjcy',
[start:run]   keypair: XfrKeyPair { ptr: 6750216 },
[start:run]   privateStr: 'h9rkZIY4ytl1MbMkEMMlUtDc2gD4KrP59bIbEvcbHFA='
[start:run] }
[start:run] abar to bar result handle!!! 4b08a55e240263e694189a53c217ea1f359f76f486c95066026676952a391548

and now it is second run with the same abars . as you can see here is a new randomizer (which should not happen as the previous two bars should be spent) and a new tx hash, (which should not happen either as tx should not be successfully broadcasted)

randomizer EuH7EoT6SB1SaZhWZ8jx9KTmTrGbqXvqzCFHdeerLMND
tx hash abar to bar result handle!!! 9dcdb0b09a998250b6152f6353cccc1712fc86088bf53fed8e86ea1b4ca69ee1

[start:run] Connecting to "http://127.0.0.1"
[start:run] 🚀 ~ file: run.ts ~ line 1396 ~ abarToBar ~ ownedAbarToUseAsSource {
[start:run]   axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
[start:run]   randomizer: 'DzmNY4BZVUC8rcYWUE55MAuuHFsw314hhpN9uwDX3BiY',
[start:run]   abarData: {
[start:run]     atxoSid: 2,
[start:run]     ownedAbar: {
[start:run]       amount_type_commitment: '7m_3n8o_pnTlLpyvjXrU11_LOmuO8Q1REe4baYCysTg=',
[start:run]       public_key: 'ytYXooOlDUX2ppmSYdFblQb-HiGu0TQ_C6PqY2sHu1E='
[start:run]     }
[start:run]   }
[start:run] }
[start:run] 🚀 ~ file: run.ts ~ line 1407 ~ abarToBar ~ ownedAbarToUseAsFee {
[start:run]   axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
[start:run]   randomizer: 'EECfEi8EPdxLWX2LDMSRdPLwESgtNnQVH3ZrxLtRFz1t',
[start:run]   abarData: {
[start:run]     atxoSid: 1,
[start:run]     ownedAbar: {
[start:run]       amount_type_commitment: 'SFgsqFHnlYEF1OlN8CbI9QxV-gA0lZTrUmJ_1XYJ5Ao=',
[start:run]       public_key: 'v-UquTlv4uIEVsL4uarScI5csl-Fko7EFk61tkl0AeM='
[start:run]     }
[start:run]   }
[start:run] }
[start:run] 🚀 ~ file: tripleMasking.ts ~ line 542 ~ randomizers { randomizers: [ 'EuH7EoT6SB1SaZhWZ8jx9KTmTrGbqXvqzCFHdeerLMND' ] }
[start:run] 🚀 ~ file: tripleMasking.ts ~ line 547 ~ randomizers { randomizers: [ 'EuH7EoT6SB1SaZhWZ8jx9KTmTrGbqXvqzCFHdeerLMND' ] }
[start:run] 🚀 ~ file: run.ts ~ line 1413 ~ abarToBar ~ abarToBarData {
[start:run]   anonKeysSender: {
[start:run]     axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
[start:run]     axfrSecretKey: 'Gsppgb5TA__Lsry9TMe9hBZdn_VOU4FS1oCaHrdLHQCgOiwRkH26riOjFwzrET33dcd1LAGz3TPYMTODtDNK6w==',
[start:run]     decKey: 'oAOZEUWKbgjv8OVtlL5PJYrNnV1KDtW3PCyZc30SW0Y=',
[start:run]     encKey: 'eT39SV2et8ONJsN0kCEPJkNQys89UlFUsdPpY2x5qR8='
[start:run]   },
[start:run]   randomizers: [ 'EuH7EoT6SB1SaZhWZ8jx9KTmTrGbqXvqzCFHdeerLMND' ]
[start:run] }
[start:run] 🚀 ~ file: run.ts ~ line 1413 ~ abarToBar ~ receiverWalletInfo {
[start:run]   keyStore: Uint8Array(188) [
[start:run]     193, 117,  11,  92, 158, 152, 166, 120, 214, 243,  52, 176,
[start:run]      12, 248,  84, 104, 204, 148, 202, 140,  35,  12,  80,  30,
[start:run]     214,  67,  48, 112,  31,  62,  28, 161, 150,  49,  87, 201,
[start:run]     211, 141, 172, 223, 206,  15, 131,   4, 240, 169, 249, 237,
[start:run]     251, 201, 183, 101, 176,  12, 244, 250, 210, 255, 185, 225,
[start:run]     215, 181, 130,  19, 123, 134, 139,  50, 125,  44, 213, 122,
[start:run]     151,  38,  63, 253, 182,  61,  74,  27, 185,  47,  56,  75,
[start:run]     190, 175, 126, 211, 253, 148, 194, 103,  46, 186, 205,  47,
[start:run]     244,  16,  69, 176,
[start:run]     ... 88 more items
[start:run]   ],
[start:run]   publickey: 'NmpU7bLld5JNndmzHozTjpkMBQmA2SAJBlHPumAaNhQ=',
[start:run]   address: 'fra1xe49fmdju4meynvamxe3arxn36vscpgfsrvjqzgx288m5cq6xc2q0ndjcy',
[start:run]   keypair: XfrKeyPair { ptr: 6750216 },
[start:run]   privateStr: 'h9rkZIY4ytl1MbMkEMMlUtDc2gD4KrP59bIbEvcbHFA='
[start:run] }
[start:run] abar to bar result handle!!! 9dcdb0b09a998250b6152f6353cccc1712fc86088bf53fed8e86ea1b4ca69ee1

also,
after checking owned abars for this anon wallet and checking balances for these randomizers, you can see it is 0, or empty, so clearly tx went somewhere else or was falsely successfully broadcasted

[start:run] Connecting to "http://127.0.0.1"
[start:run] 🚀 ~ file: run.ts ~ line 1298 ~ getAbarBalance ~ givenRandomizersList to check [
[start:run]   'EuH7EoT6SB1SaZhWZ8jx9KTmTrGbqXvqzCFHdeerLMND',
[start:run]   '8MLCqoSD9afdKdCoNyyCXRPxfvyq7oT68UH6RpcSHiGo'
[start:run] ]
[start:run] 🚀 ~ file: tripleMasking.ts ~ line 279 ~ ownedAbarsResponse []
[start:run] 🚀 ~ file: tripleMasking.ts ~ line 279 ~ ownedAbarsResponse []
[start:run] 🚀 ~ file: run.ts ~ line 1291 ~ getAbarBalance ~ balances {
[start:run]   axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
[start:run]   balances: []
[start:run] }

Environmental information

operating system:
Mac os

Code version:
feat_fo_931_abar_to_bar for sdk and feat-triple-masking-v3 for platform

Steps to reproduce

1、
Configure your local env to use triple masking branch and have your account funded from the faucet and some abars being sent to a new anon wallet

2、
please used SDK branch feat_fo_931_abar_to_bar , please note, that abarToBar function in run.ts needs to have your own abar and randomizers info, as well as the wallet info where the abar needs to be sent to and the sender anon wallet info

  const walletInfo = await Keypair.restoreFromPrivateKey(pkey, password);

  const anonKeysSender = {
    axfrPublicKey: 'oDosEZB9uq4joxcM6xE993XHdSwBs90z2DEzg7QzSus=',
    axfrSecretKey: 'Gsppgb5TA__Lsry9TMe9hBZdn_VOU4FS1oCaHrdLHQCgOiwRkH26riOjFwzrET33dcd1LAGz3TPYMTODtDNK6w==',
    decKey: 'oAOZEUWKbgjv8OVtlL5PJYrNnV1KDtW3PCyZc30SW0Y=',
    encKey: 'eT39SV2et8ONJsN0kCEPJkNQys89UlFUsdPpY2x5qR8=',
  };

  // rnadomizer for abar to be sent
  const givenRandomizerOne = '3PaExNx4SXNnhhE2pVpNiNHpiSXFQThh8qPgUycUDG5G';

  // randomizer to pay fee
  const givenRandomizerTwo = '3NcCcc493iSc2QcTuEGVwSb5vLDHDVpHHEcPPCPUN9Bp';

  const ownedAbarsResponseOne = await TripleMasking.getOwnedAbars(
    anonKeysSender.axfrPublicKey,
    givenRandomizerOne,
  );

3、
run yarn and yarn start.

estimate_gas is too larger than used_gas

Problem Description

description:
estimate_gas is too larger than used_gas, this will cause confusions for the contract developers.
Screenshots:

Environmental information

operating system:
linux
service:

Code version:

Steps to reproduce

1、

2、

3、

Code auditing: undelegate_partially()

service: platform

Code version: v0.2.1-release

The lines

I guess the actual_am is the correct number to be used in the lines below

https://github.com/FindoraNetwork/platform/blob/v0.2.1-release/src/ledger/src/staking/mod.rs#L897
https://github.com/FindoraNetwork/platform/blob/v0.2.1-release/src/ledger/src/staking/mod.rs#L902

It potentially causes cheating in this underflow case when pu.am > actual_am.
https://github.com/FindoraNetwork/platform/blob/v0.2.1-release/src/ledger/src/staking/mod.rs#L783

EVM update smart contract data does not work and breaks evm

Problem Description

description:
When trying to update a data on a deployed smart contract, it crashes the node0

Screenshots:

update_cotract_breaks_node.mp4

Environmental information

operating system:
mac os
service:

Code version:

develop on this hash

Steps to reproduce

1、
having local findora evm running, execute smart contract test by running yarn test:contract:create from SDK. that would create and deploy a smart contract and run tests , and last ne is the one which is failing

evm block chain browser to view evm transaction details, click hash and report 502

Problem Description

description:
evm block chain browser to view evm transaction details, click hash and report 502

Screenshots:

Environmental information

operating system:
ubuntu

service:
findora

Code version:
qa02:Build: testnet-evm-v0.2.7a 2021-11-26

Steps to reproduce

1、open http://mainnetmock-findorascan-io.s3-website-us-west-2.amazonaws.com/transactions

2、View evm transaction details

Failed to setup a fullnode of qa02 on a local host

Problem Description

description:
Failed to start a fresh new fullnode of qa02
Screenshots:

Environmental information

operating system:

service:
dev-qa02
Code version:
Build: testnet-evm-v0.2.7a 2021-11-26

Steps to reproduce

1、

2、

3、

Abar from customer asset is not being transferred and throwing an error even though the amount matches required

Problem Description

description:

Trying to transfer an abar created from a custom asset, I am getting an error (even though the transferred amount equals to the abar amount)

Screenshots:

sids which are used have amounts of 20 FRA (to pay fee, atxo 5) and 3 TEST3 (custom asset abar to be transferred, atxo 1)

corresponding randomizers are (amount to be transferred is matching with the amount of the abar):

Environmental information

operating system:
mac os

service:
Findora SDK

Code version:
SDK no this hash 5584cb166f486cdc85913d0c07c8d943669fa349

branch feat_fo_784_abar_to_abar

platform on develop branch, hash bdabc60cceb4d382a7c2ab55afd3b2296987e347

Steps to reproduce

1、checkout SDK, run yarn

2、prepare local abars to match the test case and update tun.ts accordingly

3、run yarn start

0x1000 precompile contract is not fully compatible with IERC20 in solidity.

Problem Description

description:
Solidity will add an extcodesize check if the code is still there.
So if I use IERC20 here to interact with our precompile contracts. It would failed.

Screenshots:

Steps to reproduce

1、
Use the IERC20 token to implement a smart contract
2、
Use the contract to interact with 0x1000
3、
Transaction will revert by iszero after extcodesize

EVM-test: Fix test-revert-receipt.ts

Problem Description

description:

We couldn't get a receipt for failed transaction. https://www.notion.so/findora/Frontier-Port-8ba31d0819cc4bfd9b5afbacfaa73a30#53df4b3af7a6478a966b20689505e855
We still need to find a way to keep the receipt of failed transaction.

Environmental information

operating system: Any

service: platform

Code version:
main branch

Steps to reproduce

always

wasm create process fails with an error on current develop branch

Problem Description

Trying to create wasm on current develop branch, and the process fails and throws an error

Screenshots:

Environmental information

operating system:

service:

M1 Cpu

Code version:

current commit hash

Steps to reproduce

`self_delegation` amount is 0 by chance in validator_delegation

Problem Description

description:

https://prod-mainnet.prod.findora.org:8668/validator_delegation?address=09EF1DB6B67D1CBF7EBA6BD9B204611848993DF7&epoch_size=5400&epoch_cnt=20

Screenshots:

Environmental information

operating system:

service:

Code version:

Steps to reproduce

1、

2、

3、

Error self_staking display in validator_detail.

Problem Description

description:

When a node is punished, voting_power is 0, and self_staking should be 0.

Screenshots:

Environmental information

operating system:

service:

Code version:

Steps to reproduce

1、

2、

3、

Triple Masking: Remainder returned after air to bar is not found (does not belong to the sender anon wallet)

Problem Description

description:

so, after running Abar to bar, I receive a new randomizer. (with a remainder of the fee).
Then, after querying owned bars by this randomizer, we have a response with a atxo sid (in this example it is 3), I am querying abar memo with a given atxo sid 3 and getting null as a response.

However, for another randomizer I have both owned owned bars (by the randomizer) and using a sid (in this example 2) I can get abar memo.

Screenshots:

Environmental information

operating system:
Mac os

Code version:
platform feat-triple-masking-v3 sdk feat_fo_931_abar_to_bar

Steps to reproduce

1、
perform abar to bar transfer in sdk , save the returned randomizer and try to check its balance.
then, for comparison check the balance of another randomizer (which was not created from a remainder but was created as a result of bar to abr transfer)

Code auditing: Rollback internal transfer's effect if cache_transaction fails

Problem Description

Screenshots:

Environmental information

operating system: OSX

service: platform

Code version: feat-evm-v2
https://github.com/FindoraNetwork/platform/blob/feat-evm-v2/src/components/abciapp/src/abci/server/callback/mod.rs#L179

16-bit precision asset transfer error report

16位精度资产转账报错
私钥：0GSbutUqx46unaifwRwBg-cq6w_dCZqsQG0S-wndhVc=
资产：76jTtWM6GFAmPKt-t728zGge36LMr27JZqgWkwCwOV4=
转账金额：0.0000000000000001

刘志攀分析：

delegation: failed in the transaction record, but the amount of pledged deposit increased, balance did not decrease

Problem Description

description:
failed in the transaction record, but the amount of pledged deposit increased, balance did not decrease
The delegation fails again, the pledged deposit amount increases, and the balance remains unchanged

https://prod-testnet.prod.findora.org:26657/tx?hash=0x3F763D8DE85E697B3B045E4CF294E171F1CD821692597760DF00BAF20952680C

Screenshots:

Environmental information

operating system:
ubuntu

service:
findora testnet

Code version:
Build: v0.2.0-release 2021-10-18

Steps to reproduce

1、delegation

2、view transaction history

Validator unstake will make other delegator's reward leak.

Problem Description

description:
If a validator unstake itself, all degegator of this validator will be unstaked, but after UNBOND_BLOCK_CNT the rewards, except validator self, will not pay to the address of delegators.
Screenshots:

Environmental information

operating system: Ubuntu 18.04 (WSL)

service:
http://localhost/

Code version:
branch-main
version=0.2.11

Steps to reproduce

hard-code UNBOND_BLOCK_CNT=16, and make debug_env

stt init

setup a wallet : fn setup -O node.mnemonic && fn setup -K /tmp/findora/devnet/node0/config/priv_validator_key.json

delegate to validator node0 and wait some blocks: fn delegate -n 1000000000000 --validator=611C922247C3BE7EA13455B191B6EFD909F10196

setup to node0: fn setup -O node0.mnemonic

fn unstake

go back to wallet in 1. : fn setup -O node.mnemonic

watch the status after about 18 blocks: fn show, bond=0, unbond=0, reward != 0.

Handle 0 staking gracefully

Handle 0 staking more gracefully

description: Unsure if this is caused by no funds to stake or "less than 0" as stated in the error message, but this exception should be handled more gracefully if it is an expected condition

I[2021-10-29|20:27:38.568] Executed block                               module=state height=1177621 validTxs=0 invalidTxs=0
I[2021-10-29|20:27:38.612] Committed state                              module=state height=1177621 txs=0 appHash=68D3D110D442C67994AC608266AB3AFA8D6810D95D271144C868B33EAF4B731F

# 2021-10-29 20:27:54 [pid: 6] [pidns: 4026532196]
INFO: ...
|-- file: src/components/abciapp/src/abci/staking/mod.rs
|-- line: 160
`-- column: 5
Caused By: ...
|-- file: src/components/abciapp/src/abci/staking/mod.rs
|-- line: 245
`-- column: 12
    Caused By: ...
    |-- file: src/ledger/src/store/mod.rs
    |-- line: 639
    `-- column: 16
        Caused By: staking amount of <dWRzSn7aK-nAvuAOZA98v0BtL0Ng8eTfumOFuwNMwmI=> available is less than 0
        |-- file: src/ledger/src/staking/mod.rs
        |-- line: 1920
        `-- column: 25
I[2021-10-29|20:27:54.212] Executed block                               module=state height=1177622 validTxs=0 invalidTxs=0
I[2021-10-29|20:27:54.256] Committed state                              module=state height=1177622 txs=0 appHash=68D3D110D442C67994AC608266AB3AFA8D6810D95D271144C868B33EAF4B731F

# 2021-10-29 20:28:09 [pid: 6] [pidns: 4026532196]
INFO: ...
|-- file: src/components/abciapp/src/abci/staking/mod.rs
|-- line: 160
`-- column: 5
Caused By: ...
|-- file: src/components/abciapp/src/abci/staking/mod.rs
|-- line: 245
`-- column: 12
    Caused By: ...
    |-- file: src/ledger/src/store/mod.rs
    |-- line: 639
    `-- column: 16
        Caused By: staking amount of <Gskrg4g-cbpI0zSQTlT6Qw_3qNyMEy0vhc1I0VdlqRY=> available is less than 0
        |-- file: src/ledger/src/staking/mod.rs
        |-- line: 1920
        `-- column: 25

Environmental information

operating system:
ubuntu 18.04
service:

Code version:
v0.2.8-release

Steps to reproduce

1、

2、

3、

evm>native transfer error

Problem Description

description:
evm>native 转账，交易成功，evm账户扣了0.01手续费，但是转账金额evm账户没有扣除，native账户没有增加

Screenshots:

Environmental information

operating system:
unbuntu

service:
findora

Code version:
mock-mainnet
Build: testnet-evm-v0.2.7a 2021-11-26

Steps to reproduce

1、evm账户余额2.409999fra

2、evm>native转账2.409999fra

Did not destroy utxo equal to 0

Problem Description

description:
There are many utxo equal to 0 in the account

Screenshots:

Environmental information

operating system:
ubuntu

service:
findora testnet

Code version:
Build: v0.2.0-release 2021-10-18

Steps to reproduce

1、https://prod-testnet.prod.findora.org:8668/utxo_sid/221

txpool should not accept tx with zero gas price

Problem Description

description:
On forge platform we suceed to send a tx with zero gas limit.
It should be blocked at rpc level.
ref:
https://blockscout.findorascan.io/tx/0x9a984eb4e9276e4edb025a17c417c8a25fbcafef09204249bafced9042ab9996/internal-transactions

Environmental information

operating system:

service:
EVM
Code version:
forge platform

Steps to reproduce

code to reproduce

				var rawTx = {
					"from": addressFrom,
					"nonce": 75,
					"gasPrice": 10000000000,
					// "gasLimit": gasLimit,
					"to": addressTo,
					"value": Data.value,
				};
	
				var tx = new Tx(rawTx);
				
				tx.sign(privateKey);
				var serializedTx = tx.serialize();
				
				web3.eth.sendSignedTransaction('0x' + serializedTx.toString('hex'))
				.on('receipt', console.log)

Data display problem in ‘other’ transaction records

Problem Description

description:
目前‘其他’交易记录中
1、不显示cliam记录
2、不显示evm>native交易记录
3、不显示unstake交易记录

Screenshots:

Environmental information

operating system:
ubuntu

service:
https://prod-mainnet.prod.findora.org/

Code version:
Build: v0.3.5-release 2021-12-14

Steps to reproduce

1、claim

2、evm>native transfer

3、unstake

contract deploy successfully,but getCode return 0x ;no code at

Problem Description

description:
no code at contract address.
Screenshots:

Environmental information

operating system:

service:

Code version:

Steps to reproduce

1、
clone compound project from github,deploy Comptroller contract successfully
2、
can scan on https://blockscout.findorascan.io/address/0xEDECF0D00E1d737514F64f21fdB6aF530da1A428
3、
but web3.eth.getCode("0x9f42De77AE4bD79658c6cB1A24774e08153A245F"); return 0x;
can sendtransaction ,but call function return error:CALL_EXCEPTION

After receiving the claim, the historical claim cannot be displayed

Problem Description

description:
After receiving the claim, the historical claim cannot be displayed

Screenshots:

Environmental information

operating system:
ubuntu

service:
findora

Code version:
mock-mainnet
Build: v0.3.0-release 2021-12-06

Steps to reproduce

1、claim

2、View historical claim

EVM-test: Fix test-subscription.ts

Problem Description

description:

The test case should support multiple topic conditional parameters doesn't work. https://www.notion.so/findora/Frontier-Port-8ba31d0819cc4bfd9b5afbacfaa73a30#53df4b3af7a6478a966b20689505e855
Needs to fix and make multiple topic conditional parameters working.

Environmental information

operating system: Any

service: platform

Code version:
main branch

Steps to reproduce

always

some RPC endpoints negative tests are failing for Findora EVM

Problem Description

description:
some RPC enpoints negative tests are failing on Findora EVM

Screenshots:

More details:

 ● Api Endpoint (rpc test negative) › eth_getBalance › Returns an error when params payload format is invalid

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_call › Returns an error when required parameter is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32602, "message": "Invalid params: invalid length 4, expected a 0x-prefixed hex string with length of 40."}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_call › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getBlockByNumber › Returns an error for the wrong format of the payload

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getTransactionCount › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getBlockTransactionCountByHash › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getBlockTransactionCountByNumber › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getCode › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_sendRawTransaction › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_estimateGas › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getTransactionByHash › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getTransactionByBlockHashAndIndex › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getTransactionByBlockNumberAndIndex › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getTransactionReceipt › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}

  ● Api Endpoint (rpc test negative) › eth_getLogs › Returns a proper error code for a wrong payload format parameter

    expect(received).toEqual(expected) // deep equality

    Expected: -32600
    Received: -32602

  ● Api Endpoint (rpc test negative) › eth_getLogs › Returns a proper error code for a wrong payload parameter

    expect(received).toEqual(expected) // deep equality

    Expected: -32600
    Received: -32602

  ● Api Endpoint (rpc test negative) › eth_getLogs › Returns an error when payload format is incorrect

    expect(received).not.toHaveProperty(path)

    Expected path: not "response"

    Received value: {"error": {"code": -32600, "message": "Invalid request"}, "id": 2, "jsonrpc": "2.0"}


Test Suites: 1 failed, 1 total
Tests:       17 failed, 28 passed, 45 total
Snapshots:   0 total
Time:        12.53 s
Ran all test suites matching /rpc.integration.negative.spec.ts/i with tests matching "rpc test".

Environmental information

operating system:
Not applicable as it is runs again remote env, so the network request is used.

service:

Steps to reproduce

1、
using sdk run yarn test:emv:integration:rpc:negative against Rinkeby and see it's passing

2、
using sdk run yarn test:emv:integration:rpc:negative against Rinkeby and see it's failing

View historical earnings, the wallet displays a blank screen

Problem Description

description:
View historical earnings, the wallet displays a blank screen

Screenshots:

Environmental information

operating system:
ubuntu

service:
https://prod-mainnet.prod.findora.org/

Code version:
Build: v0.3.5-release 2021-12-14

Steps to reproduce

1、View historical earnings

wasm create process fails with an error on current feat-triple-masking-v2 branch

Problem Description

Trying to create wasm on current develop branch, and the process fails and throws an error:

Screenshots:

Environmental information

operating system:

Code version:

Note: it might be related to #120

Steps to reproduce

16-bit precision transfer error

Problem Description

description:
创建自定义资产为16位精度，转账失败

Screenshots:
前端排查是由rust 方法抛出错误 undefind

Environmental information

operating system:
ubuntu

service:
findora

Code version:
QA02:Build: v0.2.2-RC3 2021-10-19

Steps to reproduce

1、wallet1创建资产asset1，精度为16

2、wallet1向wallet2转账asset1资产1.0000000000000001

3、转账失败

RPC test on local evm (send a tx to an eth address from another eth address) crashes the node0

Problem Description

As a pre-requisite of running a simple rpc test, I am trying to send a transaction (to be able to get a tx hash and block hash, as wee as the tx receipt).

beforeAll(async (done: any) => {
  const transactionObject = {
    from: ethAccountToCheck,
    to: ethContractAddressToReceive,
    value: '1000000000000000',
    gas: 1000000,
    gasPrice: 700000000000,
  };

  web3.eth
    .sendTransaction(transactionObject)
    .once('sending', function (_payload) {
      console.log('🚀 ~ IT IS SENDING file: rpc.spec.ts ~ line 37 ~ payload', _payload);
    })
    .once('sent', function (_payload) {
      console.log('🚀 ~ IT IS SENT file: rpc.spec.ts ~ line 40 ~ payload', _payload);
    })
    .once('transactionHash', function (_hash) {
      console.log('🚀 ~ file: rpc.spec.ts ~ line 44 ~ hash', _hash);
    })
    .once('receipt', function (_receipt) {
      console.log('🚀 ~ file: rpc.spec.ts ~ line 45 ~ receipt', _receipt);
    })
    .on('error', function (_error) {
      console.log('🚀 ~ ERROR file: rpc.spec.ts ~ line 51 ~ error', _error);
      done();
    })
    .then(function (receipt) {
      console.log('🚀 ~ file: rpc.spec.ts ~ line 60 ~ receipt', receipt);
      // will be fired once the receipt is mined
      const { transactionHash, blockHash, blockNumber } = receipt;

      // This block number has to be from the block `existingBlockHashToCheck`
      existingBlockNumberToCheck = blockNumber;
      // This block hash must be from the block `existingBlockNumberToCheck`
      existingBlockHashToCheck = blockHash;
      // This tx hash must be from the block `existingBlockNumberToCheck`
      existingTxHashToCheck = transactionHash;
      done();
    });
}, extendedExecutionTimeout);

every other time causes a crash of node0

How to reproduce:

send_to_evm_bug_node0_crashes.mp4

Environmental information

operating system:
mac os

Code version:
develop branch on this hash

Steps to reproduce

1、
Spin up a local env, send some balance to the eth address
2、
Check the network responses from version and status, to make sure rpc and nodes are responding
3、
Run rpc test from sdk repo and see its throwing an error
4、
again check the network responses from version and status, to make sure rpc and nodes are not responding and also by checking ps list, see that only node1 is running

Unhandled error from zen library while trying to open client asset record

Problem Description

description:

After fetching Sid from https://dev-qa01.dev.findora.org:8668/utxo_sid/14659 we are decrypting utxo item and during that process we:

recover client record from the response of the network call above (using ledger.ClientAssetRecord.from_json)

then we are retrieving owner memo (using ledger.OwnerMemo.from_json ) and trying to open client asset record (using ledger.open_client_asset_record)

and that is where the issue happens. and no meaningful error details are provided except that it is an unhandled error thrown by zei api.

This issue happens for some sids (utxo) and 14659 is one of those. for other sids decryption works fine.

Screenshots:

are provided above, in the description

Environmental information

it was found on https://dev-qa01.dev.findora.org

Steps to reproduce

run yarn start in the sdk using private key or mnemonic of the main faucet (I can provide that info in a private channel)
or, alternatively we could run it from this code snippet (this is just an example)

import findoraSdk from "@findora-network/findora-sdk.js";

const sdkEnv = {
  hostUrl: "https://dev-qa01.dev.findora.org",
  cachePath: "./cache",
};

const { default: SdkInstance } = findoraSdk.Sdk;

const {
  Keypair: KeypairApi,
  Account: AccountApi,
} = findoraSdk.Api;

SdkInstance.init(sdkEnv);

const main = async () => {
  const pkey = 'TO_BE_PROVIDED';
  const password = '123';

  const walletInfo = await KeypairApi.restoreFromPrivateKey(pkey, password);

  const balance = await AccountApi.getBalance(walletInfo);
};

main();

When sending a few tx to the address right next to each other, and checking the balance, a node is taken down

Problem Description

description:
SO if you are sending a few tx to the same address and checking the balance of the sender and the receiver right after the send, we might pretty easy have a situation that a node brakes down and stop responding.

I have talked to @harshadptl and as per him , this issue whorls be fixed in this PR #273 (comment) but that needs to be checked.

Screenshots:

Environmental information

operating system:
MackOS

service:
Findora SDK

Code version:
platform develop branch on this hash

ask is on this hash

Steps to reproduce

1、set up local platform

2、
in one terminal run yarn start (configure run.ts to check frames balance)

3、
in another terminal run several transfers using sdk cli

findoranetwork / platform Goto Github PK

platform's Introduction

Findora Platform

Licensing

Exceptions

platform's People

Contributors

Stargazers

Watchers

Forkers

platform's Issues

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

The lines

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce

Problem Description

Environmental information

Steps to reproduce