Heimdall sync without an already synced BOR about heimdall HOT 9 CLOSED

Proposal 1

Instead of querying Bor block headers and computing rootHash in the transaction (here), this proposal proposes to "propose & vote checkpoint by transaction" mechanism.

The checkpoint proposer will propose the checkpoint by sending MsgProposeCheckpoint on Heimdall:

type MsgProposeCheckpoint struct {
	Proposer        types.HeimdallAddress `json:"proposer"`
	StartBlock      uint64                `json:"startBlock"`
	EndBlock        uint64                `json:"endBlock"`
	RootHash        types.HeimdallHash    `json:"rootHash"`
	AccountRootHash types.HeimdallHash    `json:"accountRootHash"`
	TimeStamp       uint64                `json:"timestamp"`
	Sig             []byte                `json:"sig"`
}

Where Sig is proposer's signature on message,

message := keccak256(Proposer, StartBlock, EndBlock, RootHash, AccountRootHash)
Sig := ethCrypto.Sign(message, privKey)

Once the proposer proposes the checkpoint successfully and their tx gets included in the block on Heimdall, each validator will validate if a proposed checkpoint is valid. They will send MsgVoteCheckpoint in case the checkpoint is valid.

type MsgVoteCheckpoint struct {
	Proposer        types.HeimdallAddress `json:"proposer"`
	StartBlock      uint64                `json:"startBlock"`
	EndBlock        uint64                `json:"endBlock"`
	RootHash        types.HeimdallHash    `json:"rootHash"`
	AccountRootHash types.HeimdallHash    `json:"accountRootHash"`
	TimeStamp       uint64                `json:"timestamp"`
	Sig             []byte                `json:"sig"`
}

Checkpoint on mainchain

Once 2/3+1 signatures get collected through MsgVoteCheckpoint transactions, proposer can send checkpoint on mainchain by submitting message and array of sig.

Effect on sync

With this proposal, Heimdall will be making external calls or depends on Bor while syncing. In the end, Heimdall can be synced without already synced Bor node.

from heimdall.

I have multiple issues with this proposal.

• Validators won't be actually validating the sidechain state and attesting to it.
• What currently takes 1 transaction will take 300 transactions and probably even more if there are situations that require NACK.
• What currently takes X fees will take (300^X) fees
• Will bloat the sidechain state quite a lot
• We will have to ensure that the heimdall chain is high throughput otherwise other essential system functionalities like span and state-sync will get affected
• Things on the bridge will also start getting complicated, for creating a checkpoint you have to fetch 300 transactions
• Economics might also be affected, since producing checkpoint costs far more than before.

from heimdall.

Validators won't be actually validating the sidechain state and attesting to it.

It can be done at bridge side. In either case, the validator can choose not to compute the state.

What currently takes 1 transaction will take 300 transactions and probably even more if there are situations that require NACK

No NACK required. We can tally votes in EndBlocker as x/gov does.

We will have to ensure that the Heimdall chain is high throughput otherwise other essential system functionalities like span and state-sync will get affected

Yeah but multiple checkpoints voting can be done in parallel and those transactions can be processed easily in 10 mins interval. We can optimize by creating bulk fetch checkpoint votes tx from the mempool.

Things on the bridge will also start getting complicated, for creating a checkpoint you have to fetch 300 transactions

No need to fetch all transactions. One query will do it from the state.

Economics might also be affected, since producing checkpoint costs far more than before.

Similar to x/gov, we can refund fees or checkpoint deposits if it receives 2/3+1 positive votes.

from heimdall.

@jdkanani @vaibhavchellani I like proposal 1 a lot and I would suggest if we can make it like this

• Only one of the validators sends this tx and everyone else validates it.
• Once that tx is buried under one checkpoint we have 2/3+1 consensus
  Essentially eliminating the need for 300 txs yet getting 2/3+1 security.

from heimdall.

I think we should move this attestation process to Bor

• Basically, A round where everyone signs for finality
• A 2/3+1 attestation process after each span or similar to checkpoint interval.
• since sigs are there, we can use external/light bor nodes to sync Heimdall.

from heimdall.

Proposal 3

Assuming @0xAshish's proposal is 2

Use Tendermint side-channel p2p messaging to collect sigs on valid checkpoint instead of vote based consensus on Heimdall (unlike proposal 1)

tendermint/tendermint#476

Steps for the checkpoint or any external state verification on Heimdall

• The proposer will propose state-message over p2p channel
• Each validator verifies and sigs on it
• Proposer collects all sigs and broadcasts them on Heimdall
• Heimdall will take necessary action and change the state based on sigs

Why?

• No need of Mainchain or Bor during the sync
• No validator specific transaction
• Leverage of p2p layer of Tendermint

from heimdall.

Each validator verifies and sigs on it

Please elaborate on how this verification happens?

Also how will we identify the transaction type in tendermint ?

from heimdall.

PR #308 fixes this

from heimdall.

Please use the latest version and reopen if required

from heimdall.