[Keeping Etherlink Secure] 
This is a joint post from Nomadic Labs, TriliTech & Functori. 
This post discloses the vulnerabilities that prompted the last three fast track governance votes: Etherlink 7.0, 7.1 and 7.2, along with a technical description of each issue and how it was addressed. None of the vulnerabilities discussed below were exploited. They were uncovered either through our continuo...

does this mean that only certain classes of transactions are accepted in 30 seconds and others are held back for review? do you reorg, is there an allow list? like other custodial chains and stables when you have the ability to censor malicious transactions you should and i don’t see how this is any different, but that is what this is. censorship. if someone could find a sequence of bits that is ...

Earlier this month, Arthur Breitman laid out why post-quantum, and why now. Now, there is something concrete to experiment with alongside that argument: Quantumnet, a running experimental Tezos network whose consensus, manager keys and Data Availability Layer are all post-quantum. 
Stood up last week, Quantumnet is live in its first iteration and now open to community testing. It is not a preview ...

Are the bootstrap nodes online? I don’t get any peers. 
root@quantumnet:~/pqnet-tezos# echo https://$NET.$BASE/network.json 
https://quantumnet.pqpark.dal.nomadic-labs.com/network.json 
root@quantumnet:~/pqnet-tezos# curl -s https://$NET.$BASE/network.json | jq ‘.default_bootstrap_peers, .dal_config.bootstrap_peers’ 
null 
null 
root@quantumnet:~/pqnet-tezos# curl -s https://$NET.$BASE/network.jso...

Sorry, a last minute change broke network.json. This should be fixed now. 
Thank you for trying out the tutorial!

yep, looking better now, thanks!

Tezos has championed formal verification from the very beginning, but across the broader Web3 space, mathematical proofing of smart contracts has always suffered from one massive bottleneck: it was too complex, labor-intensive, and expensive for most dev teams compared to standard manual audits. 
However, recent progress with specialized LLMs and automated theorem proving is starting to change tha...

there’s no censorship of regular transactions being sent to the inbox, and even no censorship of bad/malicious ones sent, even if those manage through nefarious means to halt the sequencer. 
any bad ones that stopped the sequencer or those behind it in the inbox queue will just need to wait a bit longer to be accepted by the independent smart rollup nodes and a block formed with the tx in it, to a...

Explorer seems to be stuck on level 179828? 
 [image] 
Sep 29 21:30:59.587 NOTICE │ injected preattestation for level 189776, round 0 for delegate tz5Mnup67A2PRsMRXAZ3JhVHPyGKFdXeFd4n with consensus key ‘consensus-2’ (tz6Qa9FrKnu2tKZeTS5MVLmxo7KCka61HEF5) (operation hash: onmLxzjt9DumvDBvwso1o97E6WPeFYrXGs6xcxSv7JJfNRwj1vV)

Thank you for reporting. 
The self-hosted TzKT indexer was stalling on tz5/tz6 (post-quantum) addresses in smart-contract data (the chain itself was fine). 
It’s now fixed: the explorer is un-stuck and has caught up.

Appreciate the creation of this trial network.  My baker is up and running. Regarding the slot limitations with the XMSS keys, is it expected that further research will eliminate this constraint and bakers and baking tools will not have to manage a rotation scheme?

I had an early problem with the baker on quantumnet.  It would not attest or bake, even though running rpc get /chains/main/blocks/head/context/delegates/tz5fbi14ZunjW4V6WVYiGN1md82BNgjKW95f showed the manager key was associated with the active consensus key.   Eventually, the rpc call showed that the manager account was deactivated.  I managed to get it re-registered with a new consensus key, and...

Glad it’s running! 
The slot limit itself is inherent to XMSS: like every stateful hash-based signature scheme, a key can only produce a fixed number of signatures. It would only go away if consensus keys moved to a stateless post-quantum scheme that also supports aggregation. There is active research in this area but, to our knowledge, this remains an open research question. 
What we plan to do i...

You most likely didn’t wait long enough after the restart, and the docs set the wrong expectation for how long that wait is. 
The baker signs nothing until every tz6 key on its command line is loaded. At startup it rebuilds the Merkle tree of each XMSS key, and it only starts baking once all of them are built. So when you add the new consensus key, the old key can’t sign either until the new key’s...

Orange PI 5, 8 core 2.25 GHz, 15GB RAM.  Will give another rotation a try and restart with both keys

This time, took about 3 minutes, 45 seconds after restart

I’m about to shutdown operations.  Any concerns with missing 5 - 12 attestations per cycle on Quantumnet? As mentioned earlier, for this experiment I’m using an Orange PI 5, wireless connection (ISP service up to 500MB).  For comparison, I have an old Dell Inspiron laptop attesting nearly flawlessly on Bakingnet on a wireless connection at another location (ISP symmetrical service up to 300MB)

No concerns. Missing 5–12 attestations per cycle still puts you around 88–95% participation, so that does not affect your rewards. 
The gap with your Bakingnet laptop most likely comes from the keys rather than your connection: tz6 (XMSS) signing is much slower than ed25519/BLS, even on fast hardware, and an Orange Pi adds to that. 
Thank you for your participation!

With these new keys,  will it be recommended that bakers upgrade their hardware?  Will hardware signers like Raspberry Pi Zero 2W be sufficient?

Exact hardware requirements are still being evaluated. Our current expectation, as mentioned in the Quantumnet announcement, is that post-quantum baking will need somewhat more than the lightest Tezos setups, while staying within the range of readily available consumer hardware. So bakers running on minimal hardware may need to upgrade, but nothing specialized should be required. 
A Raspberry Pi Z...