Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests for v1.9.0 #1463

Closed
10 tasks done
aidan-kwon opened this issue Jun 24, 2022 · 16 comments
Closed
10 tasks done

Tests for v1.9.0 #1463

aidan-kwon opened this issue Jun 24, 2022 · 16 comments
Assignees
Labels
QA QA tests for version release

Comments

@aidan-kwon aidan-kwon self-assigned this Jun 24, 2022
@ghost
Copy link

ghost commented Jun 24, 2022

@hyunsooda
Copy link
Contributor

hyunsooda commented Jun 30, 2022

  • [SC] Sync of KIP71-related values #1427 (cc. @2dvorak)

    • The value transfer transactions are successfully executed unless the upperboundbasefee is not changed. Even though its value is changed by governance, the failed tx should be successfully executed by value transfer recovery. In order to test, follow the description below.
      • Turn on the value transfer recovery option in child chain.
      • Modify the governance epoch to one in parent chain.
      • Set the parent chain's lowerboundbasefee and upperboundbasefee with an arbitrary value larger than the current child chain's upperboundbasefee using governance.vote() in the console.
      • Send a transaction and see the failure for the first time and check out again successfully executed that failed tx (child chain has some logs about mismatching baseFee, e.g., Bridge tx is removed which has lower gasPrice than UpperBoundBaseFee or err="invalid gas price. It must be set to value greater than or equal to baseFee).
    • Test KIP71 works fine after Magma fork passes
      • Set kip71CompatibleBlock number to some value (e.g., 100) then see if KIP71 sync works fine after that block number is passed
  • [SC] Fixed concurrency API call bugs #1438 (cc. @2dvorak)

    • Run unit test with modified parameter (set contractPairLen in bridge_manager_test.go then run TestBridgeAliasAPIs)

@hqjang-pepper
Copy link
Contributor

hqjang-pepper commented Jun 30, 2022

@blukat29
Copy link
Contributor

blukat29 commented Jul 5, 2022

Test output

Setup

Version: v1.9.0-rc2 + #1512

docker build -t klaytn/klaytn:test .
./homi setup --baobab-test --cn-num 4 \
    --governance \
    --patch-address-book \
    --docker-image-id klaytn/klaytn:test
  • Vote UseGini=True at block 94 (applied from 150)
  • Activate AddressBook with CnStakingAmounts=[1M, 1M, 1M] at block 434 -- expected Gini: -1 because no one is above 5M
  • Add stakes so that CnStakingAmounts=[11M, 6M, 1M] at block 558~564 -- expected Gini: 0.15 = calcgini(11, 6)

Console output

> governance.chainConfig
{
  chainId: 2019,
  deriveShaImpl: 2,
  ethTxTypeCompatibleBlock: 0,
  governance: {
    governanceMode: "single",
    governingNode: "0x6dd7c0eb20ee7180d5fa5785782f29e28c5e8d72",
    kip71: {
      basefeedenominator: 20,
      gastarget: 30000000,
      lowerboundbasefee: 25000000000,
      maxblockgasusedforbasefee: 60000000,
      upperboundbasefee: 750000000000
    },
    reward: {
      deferredTxFee: true,
      minimumStake: 5000000,
      mintingAmount: 9600000000000000000,
      proposerUpdateInterval: 30,
      ratio: "34/54/12",
      stakingUpdateInterval: 60,
      useGiniCoeff: false
    }
  },
  istanbul: {
    epoch: 30,
    policy: 2,
    sub: 13
  },
  istanbulCompatibleBlock: 0,
  londonCompatibleBlock: 0,
  magmaCompatibleBlock: 0,
  unitPrice: 25000000000
}
> governance.getStakingInfo(0)
{
  BlockNum: 0,
  CouncilNodeAddrs: [],
  CouncilRewardAddrs: [],
  CouncilStakingAddrs: [],
  CouncilStakingAmounts: [],
  Gini: -1,
  KIRAddr: "0x0000000000000000000000000000000000000000",
  PoCAddr: "0x0000000000000000000000000000000000000000",
  UseGini: false
}
> governance.getStakingInfo(300)
{
  BlockNum: 180,
  CouncilNodeAddrs: [],
  CouncilRewardAddrs: [],
  CouncilStakingAddrs: [],
  CouncilStakingAmounts: [],
  Gini: -1,
  KIRAddr: "0x0000000000000000000000000000000000000000",
  PoCAddr: "0x0000000000000000000000000000000000000000",
  UseGini: false
}
> governance.getStakingInfo(600)
{
  BlockNum: 480,
  CouncilNodeAddrs: ["0x2a94c53e13e82ae05b5ad1baba356720a25fbfda", "0xefff9b972b2eca1a3276e754bd26c97d39e221c8", "0x0ae8be647a2e475ca495f2fb36071a2001eb1d0b"],
  CouncilRewardAddrs: ["0x2a94c53e13e82ae05b5ad1baba356720a25fbfda", "0xefff9b972b2eca1a3276e754bd26c97d39e221c8", "0x0ae8be647a2e475ca495f2fb36071a2001eb1d0b"],
  CouncilStakingAddrs: ["0x0c13f01b7ab9522225a17aaf8975c82a990a9090", "0x03c9683060a98b22a51a320bca8845d9065d5669", "0x2fd055b8510cf5f5c64b666f93f94bf7dd24d037"],
  CouncilStakingAmounts: [1000000, 1000000, 1000000],
  Gini: -1,
  KIRAddr: "0x4f9c272bb5003b06c0f7066d403deabad4b0b646",
  PoCAddr: "0x85eba1264f390d3f49e3be5043016e9424d85f6f",
  UseGini: true
}
> governance.getStakingInfo(700)
{
  BlockNum: 600,
  CouncilNodeAddrs: ["0x2a94c53e13e82ae05b5ad1baba356720a25fbfda", "0xefff9b972b2eca1a3276e754bd26c97d39e221c8", "0x0ae8be647a2e475ca495f2fb36071a2001eb1d0b"],
  CouncilRewardAddrs: ["0x2a94c53e13e82ae05b5ad1baba356720a25fbfda", "0xefff9b972b2eca1a3276e754bd26c97d39e221c8", "0x0ae8be647a2e475ca495f2fb36071a2001eb1d0b"],
  CouncilStakingAddrs: ["0x0c13f01b7ab9522225a17aaf8975c82a990a9090", "0x03c9683060a98b22a51a320bca8845d9065d5669", "0x2fd055b8510cf5f5c64b666f93f94bf7dd24d037"],
  CouncilStakingAmounts: [11000000, 6000000, 1000000],
  Gini: 0.15,
  KIRAddr: "0x4f9c272bb5003b06c0f7066d403deabad4b0b646",
  PoCAddr: "0x85eba1264f390d3f49e3be5043016e9424d85f6f",
  UseGini: true
}
> console.log(klay.blockNumber); governance.getStakingInfo("latest")
721
{
  BlockNum: 660,
  CouncilNodeAddrs: ["0x2a94c53e13e82ae05b5ad1baba356720a25fbfda", "0xefff9b972b2eca1a3276e754bd26c97d39e221c8", "0x0ae8be647a2e475ca495f2fb36071a2001eb1d0b"],
  CouncilRewardAddrs: ["0x2a94c53e13e82ae05b5ad1baba356720a25fbfda", "0xefff9b972b2eca1a3276e754bd26c97d39e221c8", "0x0ae8be647a2e475ca495f2fb36071a2001eb1d0b"],
  CouncilStakingAddrs: ["0x0c13f01b7ab9522225a17aaf8975c82a990a9090", "0x03c9683060a98b22a51a320bca8845d9065d5669", "0x2fd055b8510cf5f5c64b666f93f94bf7dd24d037"],
  CouncilStakingAmounts: [11000000, 6000000, 1000000],
  Gini: 0.15,
  KIRAddr: "0x4f9c272bb5003b06c0f7066d403deabad4b0b646",
  PoCAddr: "0x85eba1264f390d3f49e3be5043016e9424d85f6f",
  UseGini: true
}

@mckim19
Copy link
Contributor

mckim19 commented Jul 7, 2022

@yoomee1313
Copy link
Contributor

yoomee1313 commented Jul 11, 2022

  • consensus: add writable flag to the snapshot function #1470
    • tc1. "pass" call api functions which calls Snapshot() function - target block: voteData block, governanceData block, and see the voting is processed at expected block(next next epoch start).
    • tc2. "pass" restart the node when voting, then call api functions which calls Snapshot() function - target block: voteData block, governanceData block, and see the voting is processed at expected block(next next epoch start).
  • peer: fix multiChannelPeer ReadMsg loop to read closed ch immediately #1389: configure cn4/pn8/en8 network, 8000 rps, valuetransfertx
    • tc1. "pass" cns receives the tx load
    • tc2. "pass" ens rerecieves the tx load
    • tc3. "pass" exhaust en1's resource(e.g. klay_call)
    • tc4. "pass" exhaust pns' max connection
    • tc5. "pass" restart the other node of the connection( not the testing node), and see the connection is disconnected and reconnect.
    • tc6. "pass" remove validator from 4->3->2->1 and see the block generating is not blocked

@henry-will henry-will added this to the v1.9.0 milestone Jul 11, 2022
@JayChoi1736 JayChoi1736 added the QA QA tests for version release label Jul 11, 2022
@JayChoi1736
Copy link
Contributor

JayChoi1736 commented Jul 11, 2022

Regular QA Test

  • Rolling Update test: PASS

  • rolling.log

  • RPC/WS test: PASS

  • rpc.pdf

  • ws.pdf

  • Governance test: PASS

  • governance.log

  • Reward test: PASS

  • reward.log

  • Caver js/java test:

  • Sync test

    • Cypress Node Configuration
      • en0(m5.4xlarge, 6T): sync from 0 to 52007590
      • en1(m5.4xlarge, 6T): sync from 52007590 to 76539733
      • en2(m5.4xlarge, 6T): sync from 76539733 to 85287012
      • en3(m5.4xlarge, 6T): sync from 85394216 to 96238161
Category Result
Sync duration(0 to 52007590)  8d 8h 56m
Sync duration(52007590 to 76539733  5d 20h 26m
Sync duration(76539733 to 85287012)  6d 19h 16m
Sync duration(85394216 to 96238161) 2d 20h 12m
Unusual logs  no unusual logs.
Latest DB size  5.5T

sync_m6

  • Baobab Node Configuration
    • en_baobab(c5.4xlarge, 6T): sync from 0 to latest

Baobab sync

Category Result
Sync duration(0 ~ 96092837)  2d 5h 40m
Unusual logs  no unusual logs.
Latest DB size  262G
Grafana screenshot (Main) sync_baobab
  • Load test PASS

    • Stress: 10000 RPS load test for 30m

      • TC: transferSignedTx
      • TPS: 6300
      • CN : c6.x8large
      • block mining time : about 250ms
      • stress test
    • Reliability: 2000 RPS load test for 72h

    • TC: transferSignedTx, newValueTransferTC, newFeeDelegatedSmartContractExecutionTC

    • TPS: 1995. tps is even during the test.

    • Peer Connection: peer connection is stable

    • BlockGenerationTime: 0.994
      reliable

  • API performance test: PASS

  • TC : readBlockNumber, readGetAccount, readGetBlockByNumber, readGetBlockWithConsensusInfoByNumber

  • EN : m6i.4xlarge * 1

  • result

Version 1.8.4 1.9.0-rc.2
readBlockNumber 193901 217005
readGetAccount 95435 92448
readGetBlockByNumber 150.15 170.98
readGetBlockWithConsensusInfoByNumber 245.23 253.42

api_perf_v1.8.4.log
api_perf_v1.9.0-rc.2.log

@aidan-kwon
Copy link
Member Author

aidan-kwon commented Jul 21, 2022

Additional Test with rc.3

  • stress test @JayChoi1736
  • Base fee should increase/decrease precisely @blukat29
    • The changing gap should be the same as what we are expecting
    • The max increase rate is 5%
    • The max decrease rate is 5%
  • Value transfer between chains is possible when the base fee is changing @hyunsooda
  • All governance APIs return the correct value for new fields before/after HF (and update them to Klaytn-docs) @JayChoi1736
  • Invalid block body having an invalid gas price (< base fee) should be invalidated @yoomee1313

@hyunsooda
Copy link
Contributor

hyunsooda commented Jul 25, 2022

@aidan-kwon, An item Value transfer between chains is possible when the base fee is changing is duplicated test with the tests performed. Could you precisely elaborate on which test should be additionally performed? cc. @2dvorak

@aidan-kwon
Copy link
Member Author

@aidan-kwon, An item Value transfer between chains is possible when the base fee is changing is duplicated test with the tests performed. Could you precisely elaborate on which test should be additionally performed? cc. @2dvorak

@hyunsooda During QA process, we have merged influential PRs that can affect key operations of Klaytn. So, we try to execute some tests again to ensure the correct operation related to the change.

@hyunsooda
Copy link
Contributor

@aidan-kwon, Okay, thanks.

@JayChoi1736
Copy link
Contributor

stress_rc3

v1.9.0-rc.3
10000 RPS stress test for 30m
TC: transferSignedTx
TPS: 6300
CN : c6.x8large

@blukat29
Copy link
Contributor

blukat29 commented Jul 25, 2022

BaseFee test v1.9.0-rc.3 20220725.xlsx
Base Fee test OK

Version: v1.9.0-rc.3
For each block, send a contract executing transaction with varying gasLimit
Calculated desired BaseFee using Excel and compared against actual BaseFee in the blockchain.

@yoomee1313
Copy link
Contributor

yoomee1313 commented Jul 26, 2022

Invalid block body having an invalid gas price test passed.

en receives the block which having invalid gas price tx(24999999998), and it returns bad block with invalid baseFee error.

ERROR[07/26,09:37:44 +09] [5] ########## BAD BLOCK ######### Chain config: {ChainID: 940625 IstanbulCompatibleBlock: 0 LondonCompatibleBlock: 0 EthTxTypeCompatibleBlock: 0 MagmaCompatibleBlock: 5 SubGroupSize: 4 UnitPrice: 25000000000 DeriveShaImpl: 2 Engine: istanbul} Number: 5 Hash: 0x9ed658b1179560316bd0f3148c5c6a9afaaa73d2e7a358c000d43fe957872017 Receipt:  Error: invalid baseFee: have 24999999998, want 25000000000, parentBaseFee <nil>, parentGasUsed 0 

@2dvorak
Copy link
Collaborator

2dvorak commented Jul 26, 2022

Value transfer between chains was successful with below conditions (all binaries v1.9.0-rc.3).

  • Parent (before Magma) <-> Child (before Magma)
  • Parent (after Magma) <-> Child (before Magma)
  • Parent (before Magma) <-> Child (after Magma)
  • Parent (after Magma) <-> Child (after Magma)

@aidan-kwon
Copy link
Member Author

All tests have passed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QA QA tests for version release
Projects
None yet
Development

No branches or pull requests

9 participants