Federation trust

1

Something I still see difficult to grasp is that people say it is not a federation because private keys are not held by any node operator. That the keys are only in the hardware devices so it is absolutely secure and trustless.

What I need to know is: Is there any way to know in a trustless way that node operators do not have a private key copy?

2

No. Even with remote attestation you are still trusting the hardware to be working properly and not fooling you.

people say it is not a federation because private keys are not held by any node operator. That the keys are only in the hardware devices so it is absolutely secure and trustless.

Just because the keys are theoretically not accessible to the Powpeg node operators does not mean that the Powpeg is not a federated system. A federation in the context of blockchain networks is a specific governance model where independent nodes form a closed network and must come to consensus to add or remove members, and the Powpeg meets the definition.

1 Like
3

The dictionary definition of a Federation doesn’t help much. If there was absolutely no way for Pegnatories to add or remove members, you may still think about the Powpeg as a Federation.

If I define a Multisig Federation as a set of parties that have shared access to funds (private keys), then the Powpeg is not.

To summarize, is up to us how we call it, because existing definitions are fuzzy.

1 Like
4

One of the properties of the Powpeg is that if pegnatories attempt to add or remove a member without community agreement, then the community (together with miners, of course) can hardfork the platform and prevent this from happening. Powpeg migration is an open, transparent and time-delayed procedure.

I think it would be better to increase the time it takes to migrate the powpeg for every year of existence of RSK, so that it gets slower and slower over time.

2 Likes
5

@SergioDemianLerner I appreciate the efforts to decentralize RSK pegs.

  • but how can I confirm trustlessly the powpeg is in fact implemented in RSK? is there a guide to follow?
  • how can I confirm trustlessly that private keys are not held by any human being instead of PowHSMs? or worse, by just one human being. and is this a security risk anyway with powpeg in place?
  • also who is monitoring RSK to prevent pegnatories attempts to add or remove members without community agreenment in order to do a HF?
6

2 core devs are working full time to add attestation capabilities to the HSM. This means that anyone will be able to:

  • Compile the HSM firmware from source code and compute the object file hash (using deterministic compilation)
  • Check the attestation messages periodically posted to the blockchain by each pegnatory
  • Verify that the attestation signatures correspond to the hash of the object file.

The trust model is basically that the HSM manufacturer (one of the top hardware wallets manufacturer) is the ultimate trust anchor, as the device private key is cryptographically certified by the manufacturer.

This enhancement will probably be ready in the next network upgrade (not the one that is expected in April, but the next)

During the installation process, an attestation signature is generated. That signature verifies that the private key has been created by the firmware that can be validated also with attestation.

AFAIK this is already working. The pegnatories have attestations for the installations of the PowHSMs. So currently, it could be possible to verify it. However, there is no method to distribute the attestations, and that why the devs are building a system to broadcast attestations.

Some individuals are monitoring it, such as myself.
Some organizations are monitoring it, such as IOV Labs.
Pegnatories are monitoring it, because they are notified to sign (or not) the change in the composition of the powpeg.

What is missing is a how-to document so that anyone can do it.
There are 3 methods to do it:

  1. Watch calls to the Bridge contract.

If you want to follow the whole voting process, you can monitor the transactions that call the Bridge contract for calls to addFederatorPublicKey(), addFederatorPublicKeyMultikey(), createFederation(), commitFederation() and rollbackFederation().

  1. Check periodically the state of the powpeg by performing and offchain call to the Bridge contract.

You can call: getFederationAddress(), getFederationCreationBlockNumber(), getFederationCreationTime(), getPendingFederationHash(), getRetiringFederationAddress(), getRetiringFederationCreationBlockNumber(), getRetiringFederationCreationTime(),

  1. You can monitor the events created by the Bridge contract related to powpeg change

There are many events that are generated by the Bridge contract during powpeg migration, so you can watch them in any RSK blockchain explorer:
https://explorer.rsk.co/address/0x0000000000000000000000000000000001000006?__tab=events

The explorer does not have a function to filter events “commit_federation” , so you would need to download a CSV and search for it, or create a standalone dapp that connects to an RSK node to query for this event.

4 Likes
7

Thanks for your thorough response.

During the installation process, an attestation signature is generated. That signature verifies that the private key has been created by the firmware that can be validated also with attestation.

AFAIK this is already working. The pegnatories have attestations for the installations of the PowHSMs. So currently, it could be possible to verify it. However, there is no method to distribute the attestations, and that why the devs are building a system to broadcast attestations.

Can you explain what’s the nature of this attestation signature and how it works?

Funnily enough I’ve searched for “attestation signature” PowHSMs in google and the only response I’ve got is your response in this thread :slight_smile: