Hopefully they will make it easier because I fall into this category as well, without TezCapital tools it would be difficult for me to be a Baker.
BLS12-381 hasn’t been implemented in hardware but Schnorr has, which can also aggregate signatures, and it’s supported on my TPM, which I planned on using for baking. Was Schnorr considered? It could be added as tz5.
Any thoughts on using a sealed seed in a TPM, protected by v2 policies for the consensus key?
The TPM 2.0 policy authorization includes the 1.2 HMAC, locality, physical presence, and PCR. It adds authorization based on an asymmetric digital signature, indirection to another authorization secret, counters and time limits, NVRAM values, a particular command or command parameters, and physical presence. It permits the ANDing and ORing of these authorization primitives to construct complex authorization policies
With the right policies, would it be as secure as a Ledger?
This would solve the BLS12-381 performance issue, eliminate the need to have extra hardware dangling from a USB port and with the TPM 2 physical presence policy, it would make the double baking consensus key attack more difficult.
Raspberry Pi users have this option LetsTrust TPM for Raspberry Pi | The Pi Hut.
Hi Rich,
Thanks for your feedback!
After discussing it with the core engineers, it turns out that the main drawback of using Schnorr signatures for aggregation is that they require two rounds of communication. While this is acceptable for off-chain signing, it is not suitable for aggregating attestations.
For reference:
- Why Mintlayer adopts BLS signature
- MuSig | Bitcoin Optech
- Schnorr signatures for privacy and storage improvements · Issue #7315 · cosmos/cosmos-sdk · GitHub
Please let us know should you need further details!
Hi again Rich,
This track is very interesting indeed. It would require further research that we haven’t been able to conduct yet, but your feedback has been well received by the team.
We’ll keep you informed if we find anything relevant!
Hello @Nikolay-everstake,
Thanks for raising this.
We’ve added BLS/tz4 support to Signatory for Seoul. A beta release will follow once the Seoul proposal is finalized.
To the best of my knowledge, no cloud-based KMS supports BLS, and vendors are generally slow to add new asymmetric schemes.
There are many enclave solutions: they let us run code in a secure execution context, giving us flexibility to implement BLS algorithms entirely in software while maintaining strong security guarantees.
We’re currently integrating AWS Nitro Enclaves as a backend vault for Signatory. Once that’s complete, we’ll evaluate other enclave options—such as GCP Confidential Space or Confidential VMs—and I’d welcome a chat to understand your operational needs as we explore those possibilities.
Indeed, Signatory is on track to support the new tz4/BLS addresses for bakers. We have internal builds already, and we will make a beta or release candidate of Signatory when the Seoul proposal is finalized.
Initially, we will support tz4/BLS in the “File based backend” and in the AWS Nitro Enclave. Overtime, and depending on demand, we will consider adding support for more secure enclaves. Intel SGX is interesting for self-hosting bakers.
Remember this picture?
This is the Tezos RPi BLS Signer prototype.
We’ve come a long way since then, and today, we’re thrilled to introduce its open hardware repository! ![]()
What’s in this release (v0.1)?
- A ready-to-use Raspberry Pi image, with all necessary network configuration included
- Built-in support for the E-ink screen interface
- Clear, step-by-step documentation to help you set up the hardware—either using the pre-built image or by configuring everything manually
- A fully public, open-source repository ready for community contributions
Get involved!
Try it out on Seoulnet, experiment, and above all, feel free to contribute!
Let’s build something great together!
My Seoulnet baker is now running the prototype
Zir0h's Testnet bakery on seoulnet.tzkt.io