zeta-chain / node Goto Github PK
View Code? Open in Web Editor NEWZetaChain’s blockchain node and an observer validator client
Home Page: https://zetachain.com
License: MIT License
ZetaChain’s blockchain node and an observer validator client
Home Page: https://zetachain.com
License: MIT License
if for some reason some tx are not observed, we should allow third-party submission of errata tx and process it accordingly.
and replace with the new voter style #7
Verify the format of addresses on different chains, the amount, chainId, hash, etc.
Because Msg is from user input, much care must be given to validate the user input.
BasicValidation() is the first line of validation.
As part of this, chain-specific data structure and validation methods will be developed.
Current situation: The ZetaChain state machine keeps every Send (the representation of a meta-transaction that crosses chains) in its state with the Send state variable. The size of the state then grows linearly with the number of transaction. This bloats the state of ZetaChain.
Desired: The state should keep track of "pending" transaction instead. It could also keep the recent history (30 days?) for quick reference to recent transactions. The old and "done" transactions should be archived.
Why?: App state is more expensive than events stored in the Tendermint kv store (multi-store, cache, etc). Additionally, when network upgrades, the genesis file contains the whole state which can be large.
Solution: Remove old and done Send and emit events.
Impact: Old Send will not be in the state. The state machine can no longer serve as explorer. Need a separate ingestion and database to monitor and store the events and build indexes and analytics for query.
currently the keygen state variable is a singleton.
Make it a list so that subsequent keygen event can co-exist without overriding the previous ones.
panic: open /home/ubuntu/.metacore/keyring-test/val.info: too many open files
goroutine 222 [running]:
github.com/Meta-Protocol/metacore/metaclient.(*Keys).GetSignerInfo(...)
/home/ubuntu/meta-node/metaclient/keys.go:90
github.com/Meta-Protocol/metacore/metaclient.(*MetachainBridge).PostGasBalance(0xc0010ec200, {0x17b5f9a, 0x3}, {0xc00a1f8270, 0x12}, 0x5b272b)
/home/ubuntu/meta-node/metaclient/tx.go:11 +0x20d
github.com/Meta-Protocol/metacore/metaclient.(*ChainObserver).PostGasPrice(0xc0000df400)
/home/ubuntu/meta-node/metaclient/chain_client.go:287 +0x15b1
github.com/Meta-Protocol/metacore/metaclient.(*ChainObserver).WatchGasPrice(0xc0000df400)
/home/ubuntu/meta-node/metaclient/chain_client.go:159 +0x69
created by main.CreateChainClientMap
/home/ubuntu/meta-node/cmd/metaclientd/mock_multinode.go:145 +0x1ef
To prevent re-org attack, we should wait about 10 confirmations on Ethereum, and suitable confirmations on other chains.
$ curl localhost:26657/tx?hash=0xD5D89D14EF970E2325948BDF97889147280B9C5B3476FDCDC8D682E1FA9E4647
{
"jsonrpc": "2.0",
"id": -1,
"result": {
"hash": "D5D89D14EF970E2325948BDF97889147280B9C5B3476FDCDC8D682E1FA9E4647",
"height": "428878",
"index": 6,
"tx_result": {
"code": 11,
"data": null,
"log": "out of gas in location: WritePerByte; gasWanted: 200000000, gasUsed: 200024367: out of gas",
"info": "",
"gas_wanted": "200000000",
"gas_used": "200024367",
"events": [],
"codespace": "sdk"
},
"tx": "CpECCo4CCjMvemV0YWNoYWluLnpldGFjb3JlLnpldGFjb3JlLk1zZ1JlY2VpdmVDb25maXJtYXRpb24S1gEKK3pldGExOHVjYTZzdGplamRhc2dmc2Y3bjB1emQ1czNnbWRyc2o2YzVrYzMSQjB4ZjlkYmE4MDMwODNkYjA2ZGUxZjQ3YzRlYTc1NjczZWY4MGI1MmEzNWI1MjUzYTg2MDc5N2NkNjcxYzc4MDBjYRpCMHhkYzNkYzE5Nzg1NDI4M2Y1MzQ0NzI3MTA5ZWUzOGE5NGM4ODk3M2E1M2I5Y2Y3Y2YwOTk3OWM0ZGIxY2RkNjljIOmV+gIqEzEwMDAwMDAwMDAwMDAwMDAwMDAwAToDRVRIElsKUgpGCh8vY29zbW9zLmNyeXB0by5zZWNwMjU2azEuUHViS2V5EiMKIQPm7qMFXNCHrGP+JElWMYeIJ2BQB1JHPO+sRYjocYRBZRIECgIIARictTkSBRCAhK9fGkArth7Oh1oKCYvezAydkvFxxJm7dIuZHrVn1/PutZDBsBFGDwf+ajMaGWyyKQabFIse3Sg+KRj8YQ3atwtQiTeI"
}
Why does it take so much gas?
see this tx
MetaCore keeps record of the last block height of each chain
Error handling: when in doubt, use MAX_SUPPLY.
This fails on the side of caution.
Currently, every tx from zetaclient is a vote; and there are many different votes. Each vote need a state variable (poll) to track. This results in many protobuf messages.
Propose generic voter msg and poll state variable.
Every block, zetaclient will query SendAll and ReceiveAll.
These two gRPC call will return the whole list of Send and Receive, which grows linearly with the number of transactions.
It would be much more efficient to return only the "pending" ones that are still active (associated with transactions that is still in processing).
In rapid send request sometimes some of the outbound is dropped (due to nonce??) and there is no retry.
Created = 0;
Finalized = 1;
Mined = 2;
Confirmed = 3;
Currently, any successful keysign will generate a new Receive, even if the bcast might fail.
Remove Receives that are not confirmed.
otherwise, observations may be lost
right now the zetaclient reports tx broadcasted regardless of whether the broadcast succeed or not.
The problem is that when broadcast is not mined before the re-try timeout period, then new broadcast will be created, which will fail (duplicate) and zetacore is updated with invalid outTxHash.
Ideally, zetaclient only reports that when the broadcast is successful and in the mempool.
Thorchain ETH router & bifrost (observer) has suffered 2 major exploits, and the resulting super strict checking of events emited by router smart contract can still be attacked.
All exploits seem to be some form of re-enterancy attack.
Need to learn their lessons and harden the observer logic of MetaClient.
Ref the following exploit disclosure:
https://gist.github.com/HildisviniOttar/7198452b312b8b2da9510ad8b7bc75d2
Worklist for mainnet (stagenet) launch:
MetaCore needs to have an idea of validator set. This is needed to
Q who broadcast?
A the zetacore decides (randomly?)
Q how to track the tx?
A: zetaclients can't communicate directly. But the submitter can include a pointer (sendHash) in the mint event so that it can be monitored.
closes by #88
Currently things are pre-computed and hard coded.
Need to move to use real validator key generated by the buddy zetacore.
Changes:
right now the hash/address are stored in hex string (effectively base16) which wastes storage of the state machine.
For comparison, base16 uses 2 characters (2 Bytes) to encode a single byte, whereas base64 uses 4 bytes to encode 3bytes.
Changing from hex to base64 improve storage efficiency from 50% to 75%, without major changes (bytes are still encoded in string so no type change needs to be done in protobuf).
The most storage efficient encodes of course is the direct byte array ([]bytes in Go). However this requires major change to the protobuf definition.
x.y.z
x: major version: major changes that requires network upgrades; e.g. AlphaNet -> BetaNet; PoA->PoS, etc.
y: minor version: state transition function changes; requires either an "upgrade" tx from all validators, or a network re-genesis.
z: patch level: uncoordinated upgrade; no consensus rule change; e.g. zetaclient change
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.