You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feature wait 50 blocks to process Ethereum events (#338)
* create event queue for delay send tx to sifchain.
* set delay blocks as 30.
* add adr file to describe ebrelayer.
* update account according to new init.sh
* update docs
* new algorithm to handle orphan block.
* fix linter issue.
* fix two errors.
* add scripts to generate 30 new blocks.
* print out balance for check.
* print out balance for check.
* remove the eth lock in integration env, it impact the balance of ceth.
* make the transfer script send transaction according to input.
* add sleep time to make sure new block produced.
* Pull in peggy-basic-test-docker.py and test/integration/peggy-e2e-test.py from develop (commit bb368ec)
We're going to do block advancement a different way
* remove send transfer, create advanceBlock script
* fix the conflict.
* Don't wrap block advance test in an exception handler
* Require 50 block delay instead of 30
* update docs
Co-authored-by: Elliot Friedman <elliotfriedman3@gmail.com>
Co-authored-by: utx0_ <90531+utx0@users.noreply.github.com>
Co-authored-by: Elliot <34463580+ElliotFriedman@users.noreply.github.com>
Co-authored-by: James Moore <james@sifchain.finance>
In this ADR, we discuss the solution for ebrelayer how to subscribe the events from Ethereum and process these events.
13
+
### Summary
14
+
15
+
For ebrelayer, it just needs to subscribe to the events from the BridgeBank smart contract, both LogLock event and LogBurn event, then process both events and send transaction to Sifchain. Basically, there are two problems.
16
+
1. The block produced in Ethereum maybe be reorganized, most of system opt to confirm the finalization of block after 6 blocks. So it is better to process the event with some dalay. For the events once we receive from subscription, we store them in the buffer and wait for more blocks produced.
17
+
2. How to store the events, there are two options. First one is store them in memory, but events will be lost if ebrelayer restarted. Second solution is store in local db, message queue like Kafka, but will increase the complexity of ebrelayer's deployment.
18
+
19
+
## Current solution
20
+
We start to process the events happened 50 blocks before. 50 blocks can guarantee the finalization of block. Then there is no impact from block reorganization. Repeated events and invalid events are abondoned in events buffer. We choose memory to store events for now, it is simple and easy to implements. The ebrelayer will miss some events if ebrelayer restarted. Considering the whole Sifchain system is a decentralized, we can tolerate some ebrelayer offline and not send transaction to Sifnode.
21
+
22
+
### Pros and Cons
23
+
24
+
Pros: The solution is easy to implement.
25
+
26
+
Cons: The events lost if ebrelayer restart. We will store the events in persistent storage like local database or message queue system. It depends on the requirement of product in the future.
27
+
28
+
## Consequences
29
+
We will see obvious of delay for Sifchain get the message of cross-chain asset transfer. The end to end tests are impacted, need extra operations and transactions to verify the cases both transfering eth/erc20 asset to Sifchain and burn pegged Cosmos asset back to Sifchain.
0 commit comments