Poet challenge certification for round registration

[poszu]

Status quo

Currently, registration for a poet round requires proof of work. Its purpose is to guard poet from DOS in form of submitting many challenges by requiring certain amount of work to be done in order to register.

This is far from ideal for a few reasons:

• proof of work is often difficult for low-end devices while trivial for high-end ones, it's difficult to strike a balance,
• it's environmentally unfriendly,
• PoW must be repeated per each poet,

Proposal

The proposal is to substitute the PoW with a certification that the miner spent significant resources to initialize its POST data. Every node that wishes to create an ATX must create an "initial POST proof" (a proof with an empty challenge). This initial proof should be verified by a trusted certifier service and the public key of the associated miner should be signed.

Every registration to the poet should carry the certificate to prove that the miner trying to register had properly initialized POST in the past. The certificate is eternal, it doesn't expire and doesn't need to be acquired again for future registrations - it can be persisted by the node.

The poet would specify an address and public key of the certifier service it trusts on /Info endpoint.

The following diagram presents the proposed flow

Considerations for private & community poets

There are a few ways that these poets can go about the proposed solution

• reuse the certification services provided by Spacemesh (if they trust them),
• run their own certification services
• we could add an "insecure" mode in which a poet doesn't verify the certificates. It seems reasonable for private poets that are not exposed to the Internet, but it is not recommended for public community ones,
• we could add a mode in which a poet would expose the certification service by itself (as a GRPC endpoint)

We should probably provide a docker image for the certification service with clear step-by-step instructions for deployment on popular cloud(s).

Rotation of compromised certification services

We should be able to somehow change the trusted certification service in case it's compromised. The poet should return an unauthorized error code on /Submit if an invalid certificate was used. The node would then know it must re-certify.

Tasks

• implement certifier web service post-rs#146
• add support for certifier service in poet poet#427
• spacemeshos/Applications#446
• support for certifier service and registering in poet with certificates go-spacemesh#5204
• remove support for PoW poet#430
• remove support for poet PoW go-spacemesh#5212
• Support importing poet certificates go-spacemesh#5296

Opens

Custom certification services, paid poets 💵

A custom certification service could utilize any other heuristic to validate and sign the node's request. For example, it could require payment. The poet's side remains unchanged.

[noamnelke]

One thing I feel is missing here is the ability to do this process manually. There should be a way to export the PoST proof from the node and then import a certificate. I think this could come in handy in some situations and should be easy to support. E.g. what you wrote in the end about requiring payment for certification. Also private PoETs could just manually sign their users' smesher ID and then users can import the signature into their node (with no "certification service") - for this, perhaps we should allow an empty certification service URL in info and only return a public key - users who don't already have a certificate for this key won't be able to use that PoET, so error messages should be clear.

[mathcrypto]

Since the certificate doesn't expire, what happens If a user is banned by one PoET provider? Also, if the user is banned by one provider would that affect their registration to any of the other PoET providers?

[poszu]

@mathcrypto

Since the certificate doesn't expire, what happens If a user is banned by one PoET provider? Also, if the user is banned by one provider would that affect their registration to any of the other PoET providers?

A poet provider could blacklist the nodeID (not implemented). Each poet would need to blacklist separately or we could maintain some public blacklist shared by the poets).

[mathcrypto]

@poszu we have discussed the need to add PoW to protect the certifier from DoS attacks since the risk of DDOS is still there. The amount of work should exceed the work required to validate the PoST proof, to create symmetry (so submitting an invalid PoST proof would cost the attacker as much as it costs us to validate it). However I see you are completely removing it here #430