Add Clique Support #1032

holgerd77 · 2021-01-06T11:45:31Z

This PR aims to add clique support as defined in EIP-225 throughout the library stack, so likely touching Common, Block, Blockchain, eventually also Client.

Some references:

Go Ethereum Implementation

Still WIP.

Note: mention Block bug fix from def4177 in release notes

codecov · 2021-01-06T11:47:09Z

Codecov Report

Merging #1032 (6721321) into master (01243f0) will decrease coverage by 0.01%.
The diff coverage is 86.01%.

Flag	Coverage Δ
block	`81.17% <85.95%> (+2.97%)`	⬆️
blockchain	`83.01% <88.27%> (+4.49%)`	⬆️
client	`87.87% <ø> (-0.28%)`	⬇️
common	`86.79% <100.00%> (-5.16%)`	⬇️
devp2p	`82.73% <ø> (+0.24%)`	⬆️
ethash	`82.08% <ø> (ø)`
tx	`90.00% <ø> (ø)`
vm	`83.09% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

holgerd77 · 2021-01-06T17:15:44Z

Ok, made some good progress here today and we at least have got some substantial start here, this will likely take some time to mature though, there are also still larger parts missing, in particular the signer voting (respectively the extraction of an up-to-date signer list from the voting info from the blocks, read the EIP if you are interested) and the signature validation, both likely for implementation in Blockchain.

If someone has a good idea where to get or how to easily generate PoA specific blockchain test data - so a file like testdata.json but with Rinkeby or Goerli blocks - that would really helpful, got a bit stuck on this front and at the end deactivated some tests for now.

jochem-brouwer · 2021-01-06T17:22:41Z

@holgerd77 We only care about the blocks in this testdata right? The transactions in them don't really matter? If that's the case we can just pull the first ~10 blocks from Goerli/Rinkeby using web3 I'd say?

holgerd77 · 2021-01-06T17:59:12Z

@jochem-brouwer I had some problems with missing transactions as well, e.g. on running (testing) the general Block.validate() function, then the tx trie validation would fail. So optimally this would be including the tx data (if not so be it).

holgerd77 · 2021-01-13T10:35:00Z

This is now functionally ready I would say, namely this PR implements the following at this point:

Common now includes a PoA consensus configuration for the PoA clique networks (Rinkeby and Goerli)
Block performs various header field checks which are specific to Clique (timestamp diff, format of extraData which has a central role on the protocol)
Various helper functions for Block like cliqueIsEpochTransition() to comfortably request PoA related data from a block
Block: Working signature validation (the signature is included in the last 65 extraData bytes and called extraSeal)
Blockchain: extracting initial signers from the genesis block (also included in extraData and re-included for validation every EPOCH_TRANSITION blocks (so that block is then also called an "epoch transition block" with some special properties), data structure for making updated signer states persistent in DB, the structure also prepares for re-orgs where some last signer states might be deleted (deletion on re-orgs not yet implemented, should not be difficult though with the preparations done)
Blockchain: PoA clique block signature validation when validateConsensus is activated
Blockchain: added the voting mechanism (voting - to add a new signer or remove an existing one - is done repurposing some block header fields like coinbase and nonce), vote persistence in DB (also re-org ready), most of the test cases from the EIP
VM: made PoA clique ready (the COINBASE opcode returns the block signer from the extraData field on clique, since the coinbase header field has some other purpose and is not containing the actual signer)

There is some further work to be done and for example some test cases to be finished and/or reactivated, this also needs some polishing in general, so I would expect this to take another 1-2 weeks at least until we get this merged here.

Since the changes are so broad I will nevertheless put this open this for review already - together with adding a "do-not-merge" label - since it will make sense to not do an all-at-once review here but rather give some continued thoughts and polish together. You are also very invited to open PRs towards this branch if you want to continue to work here or make something better.

I have some dedicated questions and remarks as well, will put these directly along the related code parts.

Cheers 🥳 👾 🌻

Holger

ryanio · 2021-01-20T20:35:53Z

I've rebased on master and added some commits, here are the summary of changes:

Tests added for coverage:
- Test invalid extra data length (pow, poa)
- Test invalid signer list (indivisible by 20)
- Test timestamp diff between blocks is lower than PERIOD
Renamed _checkClique() to _requireClique() for increased clarity
Used Address instead of Buffer for clique signer types
Block Header:
- Add helper method hashClique()
- Renamed for clarity cliqueSignatureToAddress() -> cliqueSigner(): Address
Blockchain:
- Catch NotFoundError for clique key db reads
- Add method helper: cliqueSaveSigners(genesisBlock)
- Replaced const CLIQUE_EMPTY_BENEFICIARY = Buffer.alloc(20) with Address.isZero()

Pending TODOs I will be working on next

Test zero beneficiary (coinbase) on epoch transitions
Test non-zero mixHash
Validate signer lists on epoch transition blocks
CLIQUE_SIGNER_HISTORY_BLOCK_LIMIT is unused?

One future TODO for myself: I found having to write a lot of address1.toBuffer().equals(address2.toBuffer() so I would like to add Address.equals(address: Address) to ethereumjs-util, which would shorten many lines to address1.equals(address2). (edit: opened a PR for this here: ethereumjs/ethereumjs-util#285)

holgerd77 · 2021-01-20T21:16:59Z

Great, I'm ok with all the changes, yes, CLIQUE_SIGNER_HISTORY_BLOCK_LIMIT is not yet used, this should be integrated into the updateSignerStates method (at least that was my intention, came over it though) to not endlessly bloat the list of signer states on ongoing updates.

packages/blockchain/src/index.ts

holgerd77

Reviewed up till 893a0b4

Everything ok. 😄

packages/blockchain/src/index.ts

packages/blockchain/src/db/operation.ts

packages/block/test/header.spec.ts

packages/block/src/header.ts

packages/block/src/block.ts

ryanio · 2021-01-23T02:34:12Z

okay I believe I've completed all remaining TODOs! all tests are passing.

The last task is to handle reorgs by removing added signers and votes for deleted blocks, which I will add soon.

I also wanted to ask if we should additionally validate the difficulty field, I don't think I saw any logic for that yet:

difficulty: Contains the standalone score of the block to derive the quality of a chain.
Must be DIFF_NOTURN (1) if BLOCK_NUMBER % SIGNER_COUNT != SIGNER_INDEX
Must be DIFF_INTURN (2) if BLOCK_NUMBER % SIGNER_COUNT == SIGNER_INDEX

Another validation we can add is that ommersHash is equal to UNCLE_HASH (Keccak256(RLP([]))), I don't think it's critical, but a requirement of the spec.

(edit: realized there are still a few commented out test cases at the bottom of blockchain/test/clique.spec.ts which I will resolve)

holgerd77 · 2021-01-23T08:36:45Z

@ryanio I honestly didn't understand this whole turn-no-turn part of the spec. 😋 If you get it just implement, at the moment it is not taken in (as I also perceived this as non-mission-critical, but of course would be good to have).

The uncle validation is automatically done in Block.validateUnclesHash() which is comparing against (Keccak256(RLP([])) if the list of uncles (as checked) is empty.

holgerd77 · 2021-01-23T09:40:15Z

Have added a new factory helper method Blockchain.fromBlocksData() here 72e6fb2 for testing in the client but also for general usage, this might also be helpful for the tests here. Eventually in a subsequent PR since this needs some time to get merged in along with the other changes on client execution (will give some description along the PR later on).

packages/block/src/header.ts

…blockFromRpc)

…st cases

* remove contradictory votes for [signer, beneficiary] * clear all votes for signer after signer is added or removed * when beneficiary vote is touched/counted, count both auth and drop votes

…cently signed" * add remaining EIP-225 test cases

ryanio · 2021-01-28T07:07:13Z

ok, I believe I've completed everything and this is now ready for review!

I will give it one last look over tomorrow to see if I can add any helpful additional clarifying comments or typedocs, but meanwhile it is open for review.

Please let me know if anything can be improved or clarified. Thanks!

ryanio · 2021-01-28T07:07:24Z

packages/block/src/from-rpc.ts

@@ -44,5 +44,5 @@ export default function blockFromRpc(blockParams: any, uncles: any[] = [], optio

  const uncleHeaders = uncles.map((uh) => blockHeaderFromRpc(uh, options))

-  return Block.fromBlockData({ header, transactions, uncleHeaders })
+  return Block.fromBlockData({ header, transactions, uncleHeaders }, options)


This is a bug fix 🥴 I found common wasn't being passed properly to the returned block in blockFromRpc when using it for the goerli block test.

…ature validation)

ryanio · 2021-01-28T07:25:38Z

One thing we can consider adding in the future is a helper to create a block with a certain clique signature seal, otherwise we currently have to manually put together the extraData which can be a bit tedious. For now this might only be useful for making test data/cases (we do this in test/blockchain/clique.spec.ts:addNextBlock) until we start producing signed blocks in the client.

ryanio · 2021-01-28T07:48:21Z

This is also one last implementation detail in EIP-225 for the client when broadcasting clique blocks, noting here for subsequent work:

Authorization strategies

As long as signers conform to the above specs, they can authorize and distribute blocks as they see fit. The following suggested strategy will however reduce network traffic and small forks, so it’s a suggested feature:

If a signer is allowed to sign a block (is on the authorized list and didn’t sign recently).

Calculate the optimal signing time of the next block (parent + BLOCK_PERIOD).

If the signer is in-turn, wait for the exact time to arrive, sign and broadcast immediately.

If the signer is out-of-turn, delay signing by rand(SIGNER_COUNT * 500ms).

This small strategy will ensure that the in-turn signer (who’s block weighs more) has a slight advantage to sign and propagate versus the out-of-turn signers. Also the scheme allows a bit of scale with the increase of the number of signers.

holgerd77 · 2021-01-28T10:08:40Z

One thing we can consider adding in the future is a helper to create a block with a certain clique signature seal, otherwise we currently have to manually put together the extraData which can be a bit tedious. For now this might only be useful for making test data/cases (we do this in test/blockchain/clique.spec.ts:addNextBlock) until we start producing signed blocks in the client.

Yes, I thought this as well and already wanted to add, just couldn't come up with an API I was satisfied with so I put this aside. Think we should add this rather sooner than later, I would assume this is a somewhat common use case also useful beside our own signed block creation one.

holgerd77

Ok, have reviewed the rest of the commits, thanks Ryan, really great PR with these substantial functionality additions and completions and extensive test additions.

Have some comments (likely) to address, will nevertheless give this a go to have this huge PR out of the way.

I will also merge with admin merge for procedural reasons, since Ryan has already reviewed my initial code and I have now done the review of the remaining code changes, so technically this should make sense, hope that is ok.

holgerd77 · 2021-01-28T10:30:28Z

packages/blockchain/src/index.ts

+              if (!activeSigners.find(aSigner => aSigner.toBuffer().equals(cSigner.toBuffer()))) {
+                throw new Error('checkpoint signer not found in active signers list: ' + cSigner.toString())
+              }
+            }


This is actually just checking one way, there can still be the case that we have an active signer still there which should have been removed at some point (so the whole check should be for equality of the lists).

Won't make this a blocker for review but we likely want to add on occasion.

oh right good point, I will change to a strict equality check of the same order, that would be much better.

holgerd77 · 2021-01-28T10:41:41Z

packages/blockchain/src/index.ts

+    const limit = this.CLIQUE_SIGNER_HISTORY_BLOCK_LIMIT
+    if (length > limit) {
+      this._cliqueLatestVotes = this._cliqueLatestVotes.slice(length - limit, length)
+    }


This was my initial thought as well to trim both the signer states AND the votes (sorry, just looked it up, also still had this as a comment in along CLIQUE_SIGNER_HISTORY_BLOCK_LIMIT), but the votes actually can't/shouldn't be discarded, these can always still be relevant for vote count (not even directly after an epoch transition block since there can incidentally be a reorg directly upon/around an epoch transition block).

So I guess for the votes we might want to define a safe-number-of-blocks waiting periods (longest anticipated reorg block counts) and then discard the votes from before the epoch transition.

right now all votes are being cleared on epoch transitions:

ethereumjs-monorepo/packages/blockchain/src/index.ts

Lines 822 to 826 in 6721321

if (this._common.consensusAlgorithm() === 'clique') {

// Reset all votes on epoch transition blocks

if (header.cliqueIsEpochTransition()) {

this._cliqueLatestVotes = []

await this.cliqueUpdateVotes()

which is correct as per this part of the spec:

Attack vector: Spamming signer

... The solution is to place a moving window of W blocks after which votes are considered stale. We’ll call this an epoch.

Keeping in mind reorgs would be important though as you mention, but I have to think more about how we would manage that.

Perhaps we could keep some history of stale votes, but the vote counting logic in cliqueUpdateVotes should only count votes from the last active epoch in case of this edge scenario? starts getting a bit tricky 🤔

(edit: I added this to the new follow up PR)

I don't actually think it's too tricky: if there is a reorg, then all vote and signer state entries with block numbers higher than the reorg block number will be deleted, the signers from the last singer state stack item will be become the new active signers. Everything else from that moment on then continues (restarts) as before.

If I don't get this wrong, votes need to be kept relatively long in this scenario, so i think "EPOCH_LENGTH + REORG_SAFE_PERIOD" block numbers - so something like 30050, since if a reorg is happening from let's say 30020 -> 29950 and there is voting taking place in these last 50 blocks before the epoch transition, theoretically all existing votes from this 0-29999 epoch might be relevant for the pre-epoch voting. Does this make sense?

For Signer States I would think - all states from the last REORG_SAFE_PERIOD blocks + minimally one state - should be enough if I am not forgetting something.

But I think we can also generally be a bit more generous here - e.g. take a somewhat longer REORG_SAFE_PERIOD of 100 or something or keep more signer states, nothing lost here, this doesn't take that much space and eventually the date might be interesting for analytical purposes.

holgerd77 · 2021-01-28T10:47:17Z

packages/blockchain/src/index.ts

+    const length = this._cliqueLatestSignerStates.length
+    const limit = this.CLIQUE_SIGNER_HISTORY_BLOCK_LIMIT
+    if (length > limit) {
+      this._cliqueLatestSignerStates = this._cliqueLatestSignerStates.slice(length - limit, length)


My idea for CLIQUE_SIGNER_HISTORY_BLOCK_LIMIT was to have a defined period of blocks (therefore the name) and delete the old signer states once these number of blocks have passed. Not sure, this version of just keeping some number of signer states should work as well - I guess - but then I would rename the constant.

Also maybe 100 might be a bit too much then? But not sure, maybe that's ok, shouldn't be too much extra data.

holgerd77 · 2021-01-28T10:48:00Z

packages/block/src/from-rpc.ts

@@ -44,5 +44,5 @@ export default function blockFromRpc(blockParams: any, uncles: any[] = [], optio

  const uncleHeaders = uncles.map((uh) => blockHeaderFromRpc(uh, options))

-  return Block.fromBlockData({ header, transactions, uncleHeaders })
+  return Block.fromBlockData({ header, transactions, uncleHeaders }, options)


holgerd77 · 2021-01-28T10:51:13Z

packages/block/src/types.ts

@@ -130,4 +130,5 @@ export interface JsonHeader {

 export interface Blockchain {
  getBlock(hash: Buffer): Promise<Block>
+  cliqueActiveSigners(): Address[]


Ah, this is - as far as I oversee - the only breaking change up till now in the PR. Maybe we don't want to do this for now and keep the option of doing a non-breaking release? 🤔

Update: ah, just seeing that this is in Block. A bit confused, are people likely using this or is this just for us for testing purposes?

ah I needed this for the validateCliqueDifficulty method which needs to calculate if the signer is in or out of turn. I thought it would be good in the block header next to the pow difficulty check method, but you are right that it adds to the blockchain interface here. I can move it over to blockchain and leave the interface here as before if you think that would be better.

Just rechecked, so if this is used for typing in Block functions like async validate(blockchain: Blockchain): Promise<void> then this change is definitely breaking on backwards-compatibility, so we should find another solution here.

Maybe alternatively just leave the interface as-is and manually check in validateCliqueDifficulty() for blockchain.cliqueActiveSigners() to be present and if not throw? And additionally add some notes on the blockchain consuming methods in Block that these methods needs a clique supporting Blockchain object if run with a PoA setting? 🤔

Not sure if this is the best/optimal solution though.

that sounds like a good solution for now, I like keeping the validation in the block header since it's a logical place to validate the difficulty (although it requires the context of blockchain).

i can be convinced to move it but let's see how the solution looks this way. (added in commit: d58a901)

holgerd77 · 2021-01-28T11:37:17Z

packages/common/src/types.ts

+    clique: {
+      period: number
+      epoch: number
+    }


This was too strict and breaks typing in non-PoA contexts, have fixed this in 6fe4a1d.

ok great, I was wondering, it might be helpful if all the options were optional, at least for my use in forCustomChain , I only wanted to set epoch to 3, but I had to provide all the other values:

ethereumjs-monorepo/packages/blockchain/test/clique.spec.ts

Lines 535 to 548 in 6721321

const common = Common.forCustomChain(

'rinkeby',

{

consensus: {

type: 'poa',

algorithm: 'clique',

clique: {

period: 15,

epoch: 3,

},

},

},

'chainstart'

)

I understand this is a limitation of how the code is set up in forCustomChain though, since it's using the spread operator, it does not allow for deep nesting replacement of single values, it would replace the whole block provided. Not sure if there is a better technique we could use.

Wouldn't be a fan if we loosen this here in general since the type safety of these chain and HF definition JSON files is so underdeveloped already and should rather be improved towards the other side at some PiT. I get the point though. Allow any here for the function signature as the most simple/naive solution? 😜 Not sure, if there is something better, this should of course be preferred.

yeah, agree, in general would love some more type safety in common coming from the json files.

what I meant though is I would love to do this:

const common = Common.forCustomChain( 'rinkeby', { consensus: { clique: { epoch: 3 } } }, 'chainstart' )

however the current way the code is set up, then { consensus: type, algorithm, clique: { period } } would all be undefined. we would need some more sophisticated logic for deeply replacing nested values, rather than the simple solution of using the spread operator (here).

Ah ok, thanks for the clarification.

ryanio · 2021-01-28T19:44:09Z

One thing we can consider adding in the future is a helper to create a block with a certain clique signature seal, otherwise we currently have to manually put together the extraData which can be a bit tedious. For now this might only be useful for making test data/cases (we do this in test/blockchain/clique.spec.ts:addNextBlock) until we start producing signed blocks in the client.

Yes, I thought this as well and already wanted to add, just couldn't come up with an API I was satisfied with so I put this aside. Think we should add this rather sooner than later, I would assume this is a somewhat common use case also useful beside our own signed block creation one.

just thinking about this, how about a new BlockOption:

/**
 * Provide a [Address, privateKey] to seal clique block with this signer.
 * Will throw if provided on non-clique chains.
 */
cliqueSigner?: [Address, Buffer]

then I can create a helper method that would easily concat it with the passed-in (or blank) extraData.

(edit: actually looks like we only need the privateKey, not the address)

holgerd77 · 2021-01-29T10:55:34Z

One thing we can consider adding in the future is a helper to create a block with a certain clique signature seal, otherwise we currently have to manually put together the extraData which can be a bit tedious. For now this might only be useful for making test data/cases (we do this in test/blockchain/clique.spec.ts:addNextBlock) until we start producing signed blocks in the client.

Yes, I thought this as well and already wanted to add, just couldn't come up with an API I was satisfied with so I put this aside. Think we should add this rather sooner than later, I would assume this is a somewhat common use case also useful beside our own signed block creation one.

just thinking about this, how about a new BlockOption:
/**
 * Provide a [Address, privateKey] to seal clique block with this signer.
 * Will throw if provided on non-clique chains.
 */
cliqueSigner?: [Address, Buffer]
then I can create a helper method that would easily concat it with the passed-in (or blank) extraData.

(edit: actually looks like we only need the privateKey, not the address)

I think that's an option, at some point I also thought about adding an option to the constructor, do you think this is ok from a security PoV to request the private key from the signer? This was my main reason to hesitate, but rather based on some blurry feeling than some more solid analysis here.

P.S.: not sure if this was clever - at least it gives a neutral perspective - just to let you know that I answered these questions here before looking at your follow-up clique PR #1074.

holgerd77 added type: feature PR state: WIP package: block package: blockchain package: common labels Jan 6, 2021

holgerd77 force-pushed the add-clique-support branch from 634758f to a634a84 Compare January 11, 2021 10:06

holgerd77 added PR state: do-not-merge PR state: needs review package: vm and removed PR state: WIP labels Jan 13, 2021

This was referenced Jan 15, 2021

Breaking Releases - Meta Issue (VM v6, others) (old) #1024

Closed

Block: Encapsulate Consensus Mechanism #1044

Closed

Client v0.1 Release Planning (PoA / Yolo v3) #1045

Closed

Tracking Issue: Planned Releases #1046

Closed

ryanio added the PR state: WIP label Jan 20, 2021

ryanio force-pushed the add-clique-support branch from f72c975 to 893a0b4 Compare January 20, 2021 20:34

holgerd77 commented Jan 21, 2021

View reviewed changes

packages/blockchain/src/index.ts Outdated Show resolved Hide resolved

holgerd77 commented Jan 21, 2021

View reviewed changes

ryanio force-pushed the add-clique-support branch from 893a0b4 to 436067a Compare January 23, 2021 02:18

jochem-brouwer reviewed Jan 23, 2021

View reviewed changes

packages/block/src/header.ts Show resolved Hide resolved

ryanio added 11 commits January 27, 2021 22:47

validate goerli poa block (additional fix: pass options correctly to …

def4177

…blockFromRpc)

lint:fix

ba4bb83

add comments with clique type annotations

48da84e

add validation for clique difficulty

d69444f

update param for initWithSigners to use Signer[] to dedupe code in te…

2ad875f

…st cases

fix typo

9ec8583

improve clique vote calculations to pass test cases in EIP-225:

3f983e4

* remove contradictory votes for [signer, beneficiary] * clear all votes for signer after signer is added or removed * when beneficiary vote is touched/counted, count both auth and drop votes

* add CliqueLatestBlockSigners for snapshot for calculating error "re…

d9e5558

…cently signed" * add remaining EIP-225 test cases

move clique constants to dedicated file

6cbebb3

clique: add reorg logic and tests

8c81c69

update package-lock

141159c

ryanio force-pushed the add-clique-support branch from 8bf671a to 141159c Compare January 28, 2021 06:51

ryanio added PR state: needs review and removed PR state: WIP PR state: do-not-merge labels Jan 28, 2021

ryanio reviewed Jan 28, 2021

View reviewed changes

fix vm test (use pow chain instead of poa chain, was throwing on sign…

6721321

…ature validation)

holgerd77 commented Jan 28, 2021

View reviewed changes

holgerd77 merged commit 28ea476 into master Jan 28, 2021

holgerd77 deleted the add-clique-support branch January 28, 2021 11:02

holgerd77 commented Jan 28, 2021

View reviewed changes

ryanio mentioned this pull request Jan 29, 2021

Clique small fixes / follow-up work #1074

Merged

holgerd77 mentioned this pull request Feb 15, 2021

Support PoA chains #689

Closed

holgerd77 mentioned this pull request Mar 24, 2021

EIP-225 Clique Spec Improvements ethereum/EIPs#3426

Merged

	if (this._common.consensusAlgorithm() === 'clique') {
	// Reset all votes on epoch transition blocks
	if (header.cliqueIsEpochTransition()) {
	this._cliqueLatestVotes = []
	await this.cliqueUpdateVotes()

	const common = Common.forCustomChain(
	'rinkeby',
	{
	consensus: {
	type: 'poa',
	algorithm: 'clique',
	clique: {
	period: 15,
	epoch: 3,
	},
	},
	},
	'chainstart'
	)

Add Clique Support #1032

Add Clique Support #1032

Conversation

holgerd77 commented Jan 6, 2021 • edited Loading

codecov bot commented Jan 6, 2021 • edited Loading

Codecov Report

holgerd77 commented Jan 6, 2021

jochem-brouwer commented Jan 6, 2021

holgerd77 commented Jan 6, 2021

holgerd77 commented Jan 13, 2021

ryanio commented Jan 20, 2021 • edited Loading

holgerd77 commented Jan 20, 2021 • edited Loading

holgerd77 left a comment

Choose a reason for hiding this comment

ryanio commented Jan 23, 2021 • edited Loading

holgerd77 commented Jan 23, 2021

holgerd77 commented Jan 23, 2021

ryanio commented Jan 28, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryanio commented Jan 28, 2021

ryanio commented Jan 28, 2021

Authorization strategies

holgerd77 commented Jan 28, 2021

holgerd77 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryanio Jan 28, 2021 • edited Loading

Choose a reason for hiding this comment

Attack vector: Spamming signer

holgerd77 Jan 29, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryanio Jan 28, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryanio commented Jan 28, 2021 • edited Loading

holgerd77 commented Jan 29, 2021

holgerd77 commented Jan 6, 2021 •

edited

Loading

codecov bot commented Jan 6, 2021 •

edited

Loading

ryanio commented Jan 20, 2021 •

edited

Loading

holgerd77 commented Jan 20, 2021 •

edited

Loading

ryanio commented Jan 23, 2021 •

edited

Loading

ryanio Jan 28, 2021 •

edited

Loading

holgerd77 Jan 29, 2021 •

edited

Loading

ryanio Jan 28, 2021 •

edited

Loading

ryanio commented Jan 28, 2021 •

edited

Loading