zeta-chain / node Goto Github PK

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.

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:

1. Reliable & fast signing
   a. parallel sign
   b. batch sign
2. Reliable & light observation
   a. Sequencer of discovery: light node
   b. Report & handling of missed observation
   c. Incentives & punishment for spamming
3. Events instead of state:
   a. Send struct
   b. Archive mode: historic state to provide definitive source of truth
   b. Explorer: database and API
4. Abstract chain client for non-EVM compatible chain
   a. Query full node; scan blocks; register event/tx of interest
   b. Sign & Broadcast tx
   c. Query status of tx
5. Validator management:
   a. Join/leave
   b. Jail, slashing
   c. Incentives (the signing potentially need all signers!)
6. Error/exception handling:
   a. Waiting for catchup
   b. Error sending tx to ZetaChain or external chain
7. TSS Key:
   a. Keygen for new set of validators
   b. Re-share? Automatic
8. Constraint & safety:
   a. Rate limit of funds transfered
   b. Supply check
   c. Ability to halt trade
9. Smart contracts:
   a. Integrate with uniswap v2 forks on connected chains
   b. Terraswap?
10. DevOps
    a. logging
    b. monitoring, metric
    c. Alarms
    d. Launch all the processes; restart processes
11. Refactor
    a. Abstract external chainclient

MetaCore needs to have an idea of validator set. This is needed to

1. rejects votes (application level consensus) from non-validators
2. enable validator churn

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:

• The seeding zetaclient will provide HTTP server to provide its p2p id at :8123/p2p, which other zetaclients need to query and connect to.
• Other zetaclients need to provide a SEED env variable which contains the IP of the seeding zetaclient.

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