QA for v2.0.0 #189
Comments
|
[Pending: Waiting for reflecting latest spec] EIP-7702 and KIP-228 Please find the testing code here
Running the script |
|
KIP-226 consensus liquidity Config
Setup commandsRun from
2-2. CnStakingV2 diff --git a/contracts/consensus/CnV2/CnStakingV2.sol b/contracts/consensus/CnV2/CnStakingV2.sol
index 9da1f49..856f5a3 100644
--- a/contracts/consensus/CnV2/CnStakingV2.sol
+++ b/contracts/consensus/CnV2/CnStakingV2.sol
@@ -75,7 +75,7 @@ import "../IAddressBook.sol";
contract CnStakingV2 is ICnStakingV2 {
// Constants
// - Constants are defined as virtual functions to allow easier unit tests.
- uint256 public constant ONE_WEEK = 1 weeks;
+ uint256 public constant ONE_WEEK = 0 seconds;
function MAX_ADMIN() public view virtual override returns (uint256) {
return 50;
@@ -863,7 +863,7 @@ contract CnStakingV2 is ICnStakingV2 {
require(request.value <= staking, "Value is not withdrawable.");
require(request.withdrawableFrom <= block.timestamp, "Not withdrawable yet.");
- uint256 withdrawableUntil = request.withdrawableFrom + STAKE_LOCKUP();
+ uint256 withdrawableUntil = request.withdrawableFrom + 1 weeks;
if (withdrawableUntil <= block.timestamp) {
request.state = WithdrawalStakingState.Canceled;
unstaking -= request.value;2-3. import { HardhatRuntimeEnvironment } from "hardhat/types";
import { DeployFunction } from "hardhat-deploy/types";
const name = "WKlay";
const func: DeployFunction = async ({ deployments }: HardhatRuntimeEnvironment) => {
const { deployer } = await hre.getNamedAccounts();
const res = await deployments.deploy(name, {
from: deployer,
args: [deployer],
log: true,
});
console.log(`${name} deployed at ${res.address}`);
};
func.tags = [name];
export default func;
homi setup --cn-num 4 --baobab-test --mnemonic test,junk --patch-address-book --prague-compatible-blocknumber 500 --docker-image-id yum3/kaia:v2.0.0-rc.1 --gen-type docker
# Abook Init
npx ts-node script/commander.ts abook init --num 4
# Setup balance
cast send $CN1 --value 1 --private-key $PRIVKEY
cast balance $CN1
cast send $CN3 "submitApproveStakingWithdrawal(address to, uint256 value)" 0x000000000000000000000000000000000000dead 2 --private-key $PRIVKEY
sleep 1
cast send $CN3 "withdrawApprovedStaking(uint256)" 0 --private-key $PRIVKEY
cast balance $CN3
# Deploy
hh deploy --tags CLRegistry,WKlay --reset
# Register to Registry
BLOCK_NUMBER=$(($(cast rpc eth_getBlockByNumber latest false | jq .number) + 20))
npx ts-node script/commander.ts reg register WrappedKaia $WKAIA $BLOCK_NUMBER
npx ts-node script/commander.ts reg register CLRegistry $CLREG $BLOCK_NUMBER
# Register to CLRegistry
npx ts-node script/commander.ts clreg add $NODEID1 1 $CLPOOL1 $CLPOOL1
npx ts-node script/commander.ts clreg add $NODEID2 2 $CLPOOL2 $CLPOOL2
npx ts-node script/commander.ts clreg add $NODEID3 3 $CLPOOL3 $CLPOOL3
# Mint wKAIA
cast send $WKAIA "mint(address to, uint256 amount)" $CLPOOL1 2000000ether --private-key $PRIVKEY
cast send $WKAIA "mint(address to, uint256 amount)" $CLPOOL2 10000000ether --private-key $PRIVKEY
cast send $WKAIA "mint(address to, uint256 amount)" $CLPOOL3 4000000ether --private-key $PRIVKEY
cast call $WKAIA "balanceOf(address to)(uint256)" $CLPOOL1
cast call $WKAIA "balanceOf(address to)(uint256)" $CLPOOL2
cast call $WKAIA "balanceOf(address to)(uint256)" $CLPOOL3Result
API results |
|
|
KIP-226 consensus liquidity for on-chain governance
|
p2p changes
DetailsQA with a 1-CN, 10-PN, 2-BN, 1-EN test networksetupSetup a test network with docker compose ref Also, added log messages to inspect p2p internals. resultIn the v1.0.3 version, we could see more than 2 PNs responded in the In the rc.1 version, we have 10 PNs although our intended change was to return 2 PNs (This will be fixed in the rc.2 version). In the rc.2 version, we have up to 2 PNs although there are 10 PNs in the test network. In the v1.0.3 version, we could see that EN is more likely to get empty result when we have more than 2 BNs. In the rc version, we could see that BNs are removed and PNs are filled correctly. QA using Kairos BNsetupTo reduce noise, remove EN and BN in discovered nodes. Also, increase PN entry as it might help exhausting PNs to be discovered. resultIn v1.0.3, after several restarts, EN has hard time discovering PNs: However in v2.0.0-rc.1, using the same data directory, EN could find PN right away: RPC API changes
DetailsWe can see the difference in the rpc responses. v1.0.3 v2.0.0-rc.1 |
EIP-2935 blockhash on stateEnviroment
TestI tried the bellow command for every i ∈ {2, 8, 9, 10, 11 98, 99, 100, 101, 102, 1000, 9000} and every j ∈ [1, 10000]. Block hashes
Expected response
ResultsOpen
|
|
[WIP] EIP-2537 precompiles
Config
Result |
|
EIP-7623 & KIP-223 calldata pricing
Result
|
|
Test node is full-en node. v1.0.3 node for reference is archive node. Staking APIs (kaiax/staking), Reward APIs (kaiax/reward), Supply APIs (kaiax/supply)
Test files and steps
|
|
Gov APIs (kaiax/gov), Consensus APIs (kaiax/valset)
Check consensus APIs on private network. Using this to make validator demote/promote situations.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
findnodewith up to 2 PNs #144neighborresponses #158The text was updated successfully, but these errors were encountered: