So far, developers are calling 'Spurious Dragon' a success.

Ethereum's latest hard fork, officially activated at block 2,675,000 today, comes days after the code was first tested as a solution to ongoing network performance issues. Among other changes, the fork will give developers the ability to delete empty accounts left by an unknown attacker that had effectively flooded the network.

While generally seen as a dangerous way to upgrade a blockchain (since it can lead to a network split if the proposed changes aren't accepted by everyone), ethereum's developers have embraced hard forks as a regular way to fix technical problems. This is ethereum's third hard fork in the last four months.

While ethereum's second fork was controversial, ending in two incompatible blockchains, the two most recent forks aim to address ongoing attacks on the network that have slowed down transactions and smart contracts.

Today's hard fork further fine-tunes the prices of opcodes that the attacker abused to cheaply spam the network with transactions, contracts and accounts, that every node on the network needed to run.

While the upgrade doesn't directly remove the empty accounts created by the attacker, it creates a way to "debloat" the blockchain.

"With this EIP, 'empty' accounts are removed from the state whenever 'touched' by another transaction," explains the fork announcement.

Although this hard fork should make it harder to attack ethereum, it's still unclear whether future attacks will impact ethereum users.

"Now lets see if the attacker has any more tricks up his sleave [sic]," reads one social media post, summing up the general sentiment.

Notably, the last few weeks have seen a decline in attacks, temporarily halting issues for users that began in September at the time of the project's annual developer conference.

So far, it seems the impact is minimal.

Shapeshift

and Kraken have temporarily halted ether trades as the hard fork finishes up, but it's worth mentioning that ethereum might have also unintentionally forked last week.

This occurred when one ethereum client, Parity, released a version that forked at a block number that was previously decided on, but later changed. This meant that nodes that didn't update from that version temporarily forked (as not everyone had upgraded from that version).

The development showcases how hard fork best practices are hard to come by, and that in a sense, each one still remains experimental.

Bridge over water image via Shutterstock