GitXplorerGitXplorer
s

relection

public
1 stars
0 forks
0 issues

Commits

List of commits on branch master.
Unverified
3d424a8406591783f67546d847b4c2480dfe6e6e

Assign tx to relayers for each period, implements #2

ss1na committed 6 years ago
Unverified
e3ef2403d0a2b73a7ef07b52453f21994fd1ac6a

Add basic description to README.md

ss1na committed 6 years ago
Unverified
c8315d9bd457991d8beed1c1f7649d47b00f8651

Prevent from withdrawing two blocks before new period

ss1na committed 6 years ago
Unverified
e4122aca14ffd988fce77282a7685dedb8adf8f1

Shrink array after relayer withdrawal

ss1na committed 6 years ago
Unverified
d775b8fad302800e11a2343af2a9e0a015f7a6b4

Activate or deactivate relayers next period after they register/deregister

ss1na committed 6 years ago
Unverified
f4ce1798eba0e9de6b498d13b77758d6993e9b29

Rename canSubmit to isElected

ss1na committed 6 years ago

README

The README file for this repository.

relection

Relection aims to facilitate collision avoidance in layer two solutions in which multiple relayers compete to submit a message to a smart contract. Collisions happen when out of all relayers who try to submit the message, only one is succesful (and potentially receives a reward) and others lose gas.

The intuition behind it is to have relayers register on-chain, deposit a stake, and randomly elect leaders who are allowed to submit messages during a period, e.g. 5 blocks. Currently, the hash of the block just before a period starts is used as source of randomness, e.g. if next period starts at block 10, the hash of block 9 will be used to calculate the index of next leader from the pool of relayers. However, block hashes are biasable (miners can withhold a block, if its hash is not beneficial to them). In the case where expected reward of submitting messages is much lower than expected reward from mining a block this shouldn't be too big of a problem.

If relayers are free to register and deregister at any moment, once the block hash which is used to determine the next leader is revealed (i.e. index of next leader in array of relayers), malicious actors can try to register/deregister in a way to increase their chance of being elected. To prevent this registration/deregistration takes effect only from the next period. To give an example, if period length is 5, and current block number is 7, registrations take effect only from block 10 (start of next period), and if current block number is 8, registrations only take effect from block 15.

Relection supports two modes. One in which only one relayer is elected to submit messages for each period. For this mode, parameter _salt of getElect and isElected must be passed as 0. The second mode is to assign a task to a relayer for one period. For example, each transaction could be assigned to a relayer for a period by passing its hash as _salt to getElect. In this mode, multiple relayers can submit messages at the same time, but there still won't be a collision, because they are responsible for mutually exclusive transactions.