Symphonious

Living in a state of accord.

Exploring Ethereum 2: Weak Subjectivity Period

Occasionally the term “weak subjectivity period” pops up in Eth2 discussions. It’s a weird concept that you can usually just watch fly by and not miss too much. But when you’re talking about how to sync an existing Eth2 chain it becomes quite important.  Probably the best resource for it is Vitalik’s post: Proof of Stake: How I Learned to Love Weak Subjectivity I’ve struggled to get my head around it and why it matters so am writing up my current understanding. There is almost certainly at least one mistake in here somewhere…

So what is the weak subjectivity period? It’s the period that a client can be offline for and when it comes back online be able to completely reliably process blocks to get to the consensus chain head. For proof of work you can always do this, but not for proof of stake. To see why not, let’s look at an example.

Say we have an Eth2 network chugging away. Once 2/3 of those validators have attested to a particular epoch it’s considered finalised and no re-orgs can change it. In order to finalise two conflicting epoch’s you’d need at least 1/3 of validators to sign conflicting attestations but doing so is a slashable offence so there’s a very strong economic incentive to not do that. That incentive is essentially what crypto-economics are all about, whether you’re talking PoW or PoS it’s not that it’s mathematically impossible to break the chain, but that it costs you more money than anyone is willing or able to spend.

At this point it sounds like you should be able to just process blocks reliably, confirm the attestations and signatures all line up and it all works out. What’s the catch?

The catch is that validators can withdraw their staked funds and stop being a validator. There are limits on how fast those withdrawals can happen but once the money is out the economic incentive to not misbehave is gone. Critically despite the validator having withdrawn the money, they still have their private key and can sign things – with no staked funds anymore they can’t be slashed for it. Nodes fully sync’d to the chain know they are no longer a validator and reject those signatures but nodes further behind don’t yet have that information and see the signature as valid.

So, if we have 1/3 of validators which have withdrawn their stake, if my node is far enough back on the chain to have not seen the withdrawal of any of those nodes, then 1/3 of the validators you currently think are valid have no incentive to be honest and can sign any blocks or attestations with complete impunity and potentially form a chain which conflicts with the finalised state but is otherwise entirely valid. They can feed you those blocks to lead you down the wrong chain.

However if your node was further along the chain to see one or more of those validators exit, you’d reject their attestations leaving less than 1/3 of the validators as dishonest and allowing you to reliably reach the real chain head.

So the weak subjectivity period is essentially how far behind your node can be before 1/3 of validators can have exited without you knowing about it. Once you  fall behind more than that, you need to confirm the chain you want to sync to out of band.

Exploring Ethereum: What happens to transactions in non-canonical blocks?

In Ethereum, there are often short forks near the head of the chain because two miners found the PoW solution for new blocks at around the same time. Only one of those chains will ultimately wind up being considered the canonical chain and any blocks from non-canonical chains wind up having no effect on the state. Non-canonical blocks may wind up being added as ommers in future blocks, but everything in this article applies regardless of whether that happens. 

If your transaction winds up in a non-canonical block, is it doomed for all time? Fortunately no. Most likely your transaction will still wind up being added to a block on the canonical chain even though it’s already wound up in a block on a discarded fork.

Firstly, your transaction might have been selected for both the non-canonical block and the block that wound up on the canonical chain. Those two blocks are part of different forks so the transaction may be valid on both. In that case, whichever chain gets picked your transaction is included. However, depending on which other transactions were picked and the effect they had on world state, your transaction may have done completely different things on each fork.

Secondly, it’s possible that a node saw the non-canonical block first and treated it as part of the canonical chain (because it was the best block known to it at the time). In that case, the node will have removed your transaction from the pending transaction pool because it was already processed.  When the block that actually wound up on the canonical chain turns up, the node will perform a chain re-org to switch to this new block and relegate the original block to a fork. If your transaction isn’t in the canonical block, good clients will re-add it to the pending transaction pool so it can be added to a future block.

If your transaction went into a block that was always seen as non-canonical, then it wouldn’t have been removed from the transaction pool in the first place and continues to wait for a chance to get into a canonical block.

Bottom line, getting included in a non-canonical block does your transaction no harm. It will generally hang around until it makes it onto the canonical chain.

Exploring Ethereum: Ommers vs Non-Canonical Blocks

One subtle detail in the way Ethereum works is that there is a difference between Ommers and Non-Canonical Blocks. It’s common for people to use the term Ommer for both of these and most of the time the difference doesn’t matter but sometimes it does.

So what is a non-canonical block? Non-canonical blocks are ones which a client imports but which don’t wind up on the canonical chain. Maybe they were on the canonical chain for a while and then a re-org switched to a different chain or maybe they were imported to a fork and spent their entire life languishing there. Either way, they don’t form part of the current consensus chain and have absolutely no effect on the world state. It’s like their transactions have never been executed and no one gets any form of miner reward for them. Non-canonical blocks must be entirely valid blocks that could form part of the canonical chain, but weren’t because we found a better chain.

Apart from not getting any mining rewards, that probably sounds a lot like an Ommer, and it is. But actually an Ommer is just a block header which has been included in the Ommer list of another block. The block does not have to be completely valid – it just has to have a valid proof of work solution and be from a fork that started within the last 6 blocks of the block that included it. The transactions are not included so there’s no verification that they were in any way valid. The miner of the Ommer gets a small reward when it is included as an Ommer and the miner of the block that includes it also gets an award for doing so.

A block can be both an Ommer and a non-canonical block, and in practice usually are. However, it is possible for a block that would be invalid to import as a canonical or non-canonical block to be included as an Ommer.

Moolah Diaries: Making inject-loader and vuetify-loader play nice

I’ve been upgrading Moolah after a long period of neglect. One of the tasks is to update it to WebPack 4. Mostly this went smoothly by just creating a new project with vue-cli and bringing its generated build setup over to replace the old one.  Then a bunch of tweaking.

One thing that did bite however, was tests using inject-loader started failing as soon as I added vuetify-loader to the project with:

Error: Module parse failed: 'import' and 'export' may only appear at the top level

There may be a better way to fix this in config, but the simple answer is to adjust the inject-loader import line from something like:

import categoryStoreLoader from 'inject-loader!categoryStore';

to:

import categoryStoreLoader from 'inject-loader!babel-loader!categoryStore';

Adding in the extra babel-loader ensures the imports are processed and replaced by require and everything works.

 

Into Eth 2 – Adding Artemis

Continuing our adventures in setting up a private beacon chain… Previously we got an Eth 1 chain with the deposit contract and successfully sent a deposit to register a new validator.  So far though, we have no way of telling if it actually worked. What we need is an actual beacon chain client.  Enter Artemis…

Step 3 – Add a Beacon Chain Client

We’ll be using Artemis, partly because I’m incredibly biased and partly because it happens to support the exact version of the deposit contract we’ve deployed (what a coincidence!).

We’ll need a config file for it, the vast majority of which is boiler plate I copied and probably don’t actually need.  The important bit though is we need to point it at our Pantheon node so it can query the ETH1 chain data. We also need to tell it the address of our deposit contract:

[deposit]
# normal, test, simulation
# "test" pre-production
# "simulation" to run a simulation of deposits with ganache-cli, if a inputFile is included the file will replay the deposits
# "normal" production, must include contractAddr and nodeUrl
mode = "normal"
...
contractAddr = "0xdddddddddddddddddddddddddddddddddddddddd"
nodeUrl = "http://eth1:8545"

Note that “eth1” is the name we gave to our Pantheon docker image. Docker will do its magic to resolve that to Pantheon’s IP address inside the container.

And then we have some relatively standard docker boiler plate in our run.sh script for it.

If you’ve followed all the steps from part 1 and actually sent a deposit transaction, when you run Artemis after a few moments it should create a JSON file in artemis/output/artemis.json containing something like:

{
"amount": 32000000000,
"eventType": "Deposit",
"merkle_tree_index": "0",
"pubkey": "0x88526BB3800ABB7BA3E4DF4255D043AA661EDDBBFDC0B8C3209034B7EEA65EB3C32AAF0E5D19E8998A1CE5E2B9B64299",
"withdrawal_credentials": "0x008098BD37974616EC6DA256B5D2650E2363D011B7CEF902F7CCBFE938CBA0EA"
}

Which is a record indicating it has received and recognised our deposit. Pretty much nothing else happens though because we still don’t have enough validators to actually get the beacon chain started.  I suspect running some 65,000 validators on my laptop might be a little ambitious so the next step is likely to be tweaking config to reduce the number of validators required before the chain starts.