POET Core Server
Plase see the spec here
POET SERVICE
Draft
Overview
- POET stands for Proofs Of Elapsed Time. It is a.k.a. proofs of sequential work. The Spacemesh POET service is a public Internet service that provides verifiable proofs of elapsed time
- It is designed to work together with Spacemesh Proofs Of Space Time (POST) commitments to provide NIPSTs - non-interactive proofs of space time
- Note that this POET project is not related to Intel POET in any way
WARNING: THIS IS A CURRENTLY AN EXPERIMENTAL REPO. DO NOT USE THIS REPO IN ANY REAL WORLD PROGRAM.
Open Design Process
- We are designing the POET service fully in the open before moving on to the open source code implementation
- You are welcome to join the design phase. Collaborators and contributors are welcomed
- To get started join our POET Gitter channel and introduce yourself
Service Requirements
- A POET service participates in the the creation of NIPSTs (Non Interactive Proofs of Space Time) as specified in the Spacemesh White Paper 1
- A POET service must be configured for a number of iterations which roughly corresponds to a time duration based on the deployed POET service CPU single core frequency. Or more accurately put, to the performance of the underlying hash function used by the service on the deployed hardware
- The POET must provide a service that allows anyone to create a NIPST for a commitment
- The POET service should be configured with a public time beacon. We plan to use the timestamp of irreversible Spacemesh blockmesh layers as the time beacon. The time beacon guarantees that a POET proof is not older than the published layer timestamp
- The POET service should be provided as an
https-json
for any client, and as an gRpc
endpoint for gRpc clients
- The POET service should work in consecutive rounds. Clients submitted statements which are received before a round starts must be part of the initial round commitment. In other words, a POET round initial statement must be a proof of all received statements before the round start
- A round may fail due to a runtime server error. The service should report failed rounds
Solution Design
- Our design follows the theoretical work of Tal Moran’s Publicly Vrifiable Proofs of Sequential Work using the improved construction published in Simple Proofs of Sequential Work
- The design will be reviewed by the Spacemesh research team before implementation begins
- We plan to initially use sha256 as the bash H hash function
- We plan to implement the service in go-lang to achieve close to native pref and native cross-platform packaging
-
The statement X used in each round to generate Hx(s):=sha-256(X||s) is defined as:
x := {Service signature on the hash of the client submitted statements sorted list || RoundId || Spacemesh blockmesh layer hash}
where || signifies binary concatenation.
- Spacemesh blockmesh layer hash: the hash of the irreversible layer used for the round. This proves that the POET proof was started after the layer timestamp.
- Client submitted statements sorted list - the statements submitted in time for participation in this round signed by the service to prove that he used them to generate the poet proof
- RoundId - current round id
POET Service Config
- A POET service is configured with one ore more
Spacemesh API gateways
. Each gateway provides the Spacemesh API
to the Spacemesh mainent. The service uses the Spacemesh API to obtain irreversible layers meta-data such as hash and timestamp
- Each service should have a crypto key pair used to sign statements created by the service and for anyone to verify statements signed by the service
- Round 0 of a POET service will not use a Spacemesh layer id as it is designed to provide the initial proof required to select validators for a Spacemesh network. For round 0 a POET service will be confiured with another form of time beacon. e.g. a recent hash of another public blockchain block to ensure that the proof was created after the block timestamp wall clock
POET Service Api
API Methods
Implementation Considerations
- The service should be implemented as an https-json service with json as both the request params and response data format
- All binary data should be
base64
encoded in json payloads
- We plan using a modern, optimized implementation of sha-256 for modern Intel CPUs (See [6])
Theoretical background and context
Related work