ARK delegates

Discover and follow ARK delegates

44
Rank

alessio


  • Is public delegate?
  • Voters: 74 (72 )
  • Voting power: 1,410,531.5
  • Payout percent:
  • Payout interval:
  • Payout MIN:
  • Payout MAX:

My proposal

I am here to present a unique delegate proposal for the Ark Ecosystem. I have been working for the last months to fix several important security vulnerabilities in Ark Node v1 and Ark Core v2 and I'd like to continue doing this, because I think it's beneficial for the future of the ecosystem for obvious reasons.

The forging rewards from delegate alessio are used to cover the funding necessary to continue my security research and code auditing for Ark Core v2 on a permanent and full time basis. All discoveries are confidentially disclosed to the Ark team who pay bounties for all confirmed vulnerabilities that are reported. These bounty rewards are then shared in full with the delegate's voters in proportion to their voting weight at the time the bounty is received.

Past experience

I worked in a team to recover the Ark Node v1 mainnet chain in October, where my duties involved writing a patch to hard fork the network, taking a clean snapshot of the blockchain (which all delegates subsequently used to restore the chain), delivering an airdrop to the delegates and retransmitting all existing transactions to ensure that no funds were lost and that no transactions could be maliciously replayed.

After that, my focus switched to Ark Core v2. You can read about some of my discoveries in the Updates section below, or by checking the official security-vulnerabilities repository on GitHub here: https://github.com/ArkEcosystem/security-vulnerabilities. The vulnerabilities reported by fun or alessio are mine.

Conclusion

In summary, I've spent many hours auditing and investigating security issues in Ark Core v2, with a proven record of repeated success and I've reported more v2 security issues than anyone else. I can only continue this work with a regular funding stream from forging rewards to cover the hours that are spent on it, and in return, the delegate voters receive their share of any bounties I get, based on the vote weight of their wallet at the time the bounty is received.

Security should be a massive concern for any cryptocurrency and I have hopefully demonstrated my skills in that regard. We need to keep the codebase secure, and this extends beyond Ark alone, as we need to think about all the other forks based on Ark and the future push-button blockchains too if we want to see mass adoption and ultimately succeed.

And if you agree with me, please consider voting for delegate alessio.


Contributions:

  • Security research, vulnerability discoveries and patches
    Please see the Updates section below or the list of vulnerabilities here: https://github.com/ArkEcosystem/security-vulnerabilities. All vulnerabilities reported by fun or alessio were made by me.

Updates:

  • 11. Jun. 2019 @ 14:21 | visit update page
    Core-SV-020: Race condition resulted in blocks containing already forged transactions: If a node received a high volume of transactions entering the transaction pool in a short time period, it would not filter out all the recently forged transactions from incoming blocks. This meant that when a delegate tried to forge, it may have included already forged transactions in its block, which would then be rejected by the network, causing the affected delegates to miss blocks until their pools were cleaned.
  • 06. Jun. 2019 @ 08:47 | visit update page
    Core-SV-019: Block header manipulation in quorum calculations prevented nodes forging: Forging nodes could be tricked into thinking they were double forging, even when they were not. This activated the automatic protection which stopped the nodes from forging. As the delegates were not actually double forging in the first place, they did not produce any blocks. If all delegates were targeted, the chain completely stopped.
  • 28. May. 2019 @ 17:38 | visit update page
    Core-SV-018: A forged second signature registration did not invalidate existing transactions from the same sender in the transaction pool: It was possible to stall the blockchain by manipulating second signature registrations. It involved broadcasting a transaction from a wallet without a second signature, then registering a second signature for that wallet which was forged prior to the initial transaction being forged.
  • 22. Apr. 2019 @ 12:07 | visit update page
    Core-SV-017: Transactions signed with a second signature prior to the second signature registration being forged halt the blockchain: A node that received a second signature registration, immediately followed by a transaction signed with that second signature prior to the second signature registration being forged in a block, would be unable to forge a new block as the second transaction was accepted by the node and added to its transaction pool but would not validate in a block since the second signature registration was not forged yet. As transactions are broadcasted to all nodes, this would stop the chain until the pools were cleared as nobody would be able to forge a block.
  • 22. Apr. 2019 @ 12:07 | visit update page
    Core-SV-016: Receiving a block containing non-valid transactions causes peers to roll back: A received block containing a transaction that cannot be applied causes all peers to roll back. The accept block handler triggered a rollback if a block contained a transaction that cannot be applied, which was unnecessary when it was a case that the current block could not be applied due to the transactions within it.
  • 22. Apr. 2019 @ 12:06 | visit update page
    Core-SV-015: Delayed block propagation causes the next delegate to miss its block: If a delegate forged a block but was late broadcasting it, the next delegate in line would forge at the wrong height as it would not have received the previous block. By the time it attempted to broadcast the block, the previous delegate's delayed block would have been received by most (or all) of the network, meaning the newly forged block at the same height would be rejected and thus the delegate would miss its block.
  • 19. Mar. 2019 @ 17:59 | visit update page
    Core-SV-014: Public API endpoint open to possible DDOS attack: Endpoint /api/v2/delegates/{delegate}/voters/balances did not paginate its results. This was a vector for DDoS as anyone could request the vote balances of every voter of a delegate in one API call. For delegates with large number of voters (>5000) this could overload the server even before the HTTP rate limiting kicked in.
  • 14. Feb. 2019 @ 14:42 | visit update page
    Core-SV-013: Transactions near to the HTTP POST payload size limit can stop delegates forging and halt the chain: The maximum HTTP POST payload is 1048576 bytes but there was no logic to ensure that blocks only contained transactions that would fit in a block below that size limit. It was possible for any network user to send deliberately oversized transactions that would approach (but not exceed) this limit. Although nodes would accept these larger transactions as valid, when it was time to forge them into a block, the additional block headers would make the block size larger than 1048576 bytes. This meant all nodes would reject the block with HTTP error 413 Request Entity Too Large, so the forging node would miss its block and the oversized transactions would remain in the transaction pool, meaning the node would be unable to forge until the oversized transactions expired (the default time being 6 hours).
  • 11. Feb. 2019 @ 21:58 | visit update page
    Core-SV-012: Conflicting delegate registration transactions not detected by the transaction guard: A user could try registering the same delegate name using multiple wallets in a single block. It would result in a stalled network because no delegate would be able to forge a valid block as they would all try to forge blocks containing the conflicting transactions. If exploited maliciously, any bad actor could have stalled the network permanently by repeatedly sending conflicting transactions to ensure the transaction pools were never clean so the network could not recover.
  • 01. Feb. 2019 @ 00:37 | visit update page
    Core-SV-011: Malicious delegate 0-ARK transaction spam: The transaction schema to prevent zero-amount transfer transactions was never enforced by consensus, so zero-amount transfer transactions could be sent by a malicious delegate to spam the blockchain.
  • 01. Feb. 2019 @ 00:35 | visit update page
    Core-SV-010: Malicious delegate can cause peers to fork and roll back simultaneously: A malicious delegate could craft a block at the correct height but with a timestamp from a previous round that collided with a valid forging slot time for that delegate in the current round. This has the result that the block would be initially accepted, but, because the block was unchained due to the incorrect timestamp, it would cause the receiving node to immediately enter fork recovery mode and roll back the chain.
  • 01. Feb. 2019 @ 00:34 | visit update page
    Core-SV-009: Fake peers can be added by using non-quad-dotted notation: Peers using non-quad-dotted notation representation could be added to peer lists, which provides a denial of service vector as millions of IPv4 loopback addresses could be added to the peer list which will all resolve to the local node which would overwhelm the server.
  • 25. Jan. 2019 @ 18:43 | visit update page
    Core-SV-008: Forged blocks by anyone can cause the chain to stop/or start recovering: Anyone can broadcast signed blocks, and when receiving a forged block from a wrong generator, the chain would fork. This also applied to inactive (unknown) generators. If a malicious actor kept broadcasting such blocks, the chain would effectively cease operating.
  • 25. Jan. 2019 @ 18:43 | visit update page
    Core-SV-007: Forging multiple blocks in a slot and rewards hijacking: Any active delegate could forge multiple blocks within their allocated 8 second slot time, as long as the block IDs were different and were all sent to the same node with an incrementing block height, as each block was considered to be valid and accepted on the chain. This had the effect of generating block rewards for each of the multiple blocks that were forged in the slot, resulting in inflated rewards per round for any delegate that carried out this exploit.
  • 25. Jan. 2019 @ 18:43 | visit update page
    Core-SV-005: Double forging a block: A malicious forger could forge multiple distinct blocks and broadcast them to different peers causing instability in the network.
  • 25. Jan. 2019 @ 18:42 | visit update page
    Core-SV-004: IP spoofing: The whitelist could be bypassed by IP spoofing due to the way we determined the IP of a request. This could also be used to fill up the peer list with loopback IP addresses to cause a DoS attack and prevent block propagation.
  • 25. Jan. 2019 @ 18:42 | visit update page
    Core-SV-002: Generating new Ark using multi signature transaction: In a multi-signature transaction, the transaction handler only verified the signatures and did not properly conduct balance checks. This made it possible to generate new ARK tokens on the network utilising a multi-signature transaction.
  • 25. Jan. 2019 @ 18:37 | visit update page
    Core-SV-001: Invalid block received: The lastDownloadedBlock variable was not reset when discarding invalid blocks. This caused network nodes to continually attempt to download new blocks from the wrong height, effectively halting the network. This issue would have allowed a malicious user to disrupt network nodes and the network itself.

Nodes

  • CPU: 8
    Memory: 16384
    mainnet
  • CPU: 4
    Memory: 4096
    mainnet
    backup