The following are etc materials that need to be organized into the correct structures:
TBD (Stuff to Later Categorize)
SLA
3.2.2 Network SLA (Service Level Agreement)
Servicers are paid proportionally to how well their Relay responses meet the standards of the Network SLA. A Relay is an abstraction of a request/response cycle with additional security guarantees when interacting with Web3 resources. The quality of a service is measured by:
Availability: The Servicer's uptime
Latency: The Round-Trip-Time (RTT) of the the Servicer's response relative to when the request was sent
Data Accuracy: The integrity of the Servicer's response
Since the Fisherman may not necessarily be in the same GeoZone as the Application & Servicers, the Latency will onus will be on them to normalize the TestScores The Fisherman
3.2.3 Report Cards & Test Scores
A TestScore is a collection of samples by a Fisherman of a Servicer, based on the SLA criteria outlined above, throughout the duration of a Session.
A ReportCard is the logical aggregation of multiple TestScores over an Actor's registration lifetime.
3.2.4 Volume Estimation
The Application's Web3 usage volume is estimated through probabilistic hash collisions. This enables a concise proof of probabilistic volume, without requiring compute or memory intensive storage and aggregation. Similar to Bitcoin's Difficulty, a RelayVolumeDifficulty governance parameter will be used to determine the "difficulty", and how relay counts must be estimated.
Each relay can be viewed as an independent Bernoulli Trial that is either a volume applicable relay or not. A geometric distribution can be built of the number of relays that need to be serviced until an applicable relay is made. For example, if a SHA256 hash algorithm is used and RelayVolumeDifficulty represents 3 leading zeroes, the hash of each concat(SignedRelay, SignedRelayResponse) above 0x000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF will not be applicable for relay rewards. However, any hash below the target will receive RelayVolume rewards proportional to the likelihood of the hash. For example, 0x000FFF... would be estimate RelayVolume relays, 0x0000FF... would e estimated to 16*RelayVolume, etc...
A the end of each Session, the volume applicable relays are sent to the Fisherman for validation and salary distribution.
sequenceDiagram
actor Client
actor Servicer
participant IS as Internal State
participant ISS as Internal Storage
participant Chain as Web3 Chain
loop Repeats During Session
Client ->> Client: Sign(Relay)
Client ->> Servicer: Send(Relay)
Servicer ->> +IS: Validate(Relay)
IS ->> -Servicer: IsValid(Relay)
Servicer ->> +Chain: Execute(Relay, RelayChainURL)
Chain ->> -Servicer: RelayResponse = GetResponse(RelayChain)
Servicer ->> Servicer: Sign(RelayResponse)
Servicer ->> ISS: IfValid(Relay) -> Persist(Relay, RelayResponse)
Servicer ->> Client: Send(RelayResponse)
end
loop Repeats Every Session End
Servicer ->> +IS: GetSecretKey(sessionData)
IS ->> -Servicer: HashCollision = SecretKey(govParams)
Servicer ->> +ISS: RelaysThatEndWith(HashCollision)
ISS ->> -Servicer: VolumeApplicableRelays
Servicer ->> Fisherman: Send(VolumeApplicableRelays)
Fisherman ->> Fisherman: Validate Relay & RelayResponse
end
3.3 Fisherman Protocol Ignored for Now
Stake Burning
Application stake burn is a necessary mechanism to ensure economic equilibrium at network maturity by balancing POKT inflation and deflation.
AppBurnPerSession is a governance parameter that will dictate the amount of POKT burnt for every session an Application initiates, and AppBurnPerRelay will govern the amount of POKT burnt based on the amount of work (i.e. number of relays serviced) Servicers provided to the Application throughout the session. Given that the Application's stake will decrease with every session, new rate limiting parameters, dictated via MaxRelaysPerSession, will be set at the start of each new session.
As of updating this document, these governance parameters are expected to be 0 at the time of launching the next version of the network. More detailed tokenomic models will follow in future iterations of the specifications.
3.7.3 Pool
A Pool is a special type of Account that is completely autonomous and owned by the network. POKT can be burnt, minted and transmitted to a Pool at the protocol layer at the time of state transition (after a block is validated) without explicit transactions. Pools can be used for tasks such as fee aggregation, reward distribution and other operations based on state machine changes.
type Pool interface {
GetAccount() Account # The cryptographic ID of the account
GetName() string # The name of the pool
}
3.8 State Change Protocol
There are two categories of state changes in Pocket Network that may be included in a block:
Transactions - state changes initiated and signed by any account with or without a balance
Evidence - state changes and/or signals initiated and signed by registered/staked protocol actors
Autonomous - operations completed based on the results of the lifecycle of validated and finalized blocks
3.8.1 Transaction
Transactions are discrete state change operations executed by actors or accounts. The structure of a Transaction includes, at a minimum:
Payload: A command structured in the form of a Message (e.g. StakeMsg, PauseMsg, SendMsg, etc..)
Dynamic fee: A fee to incentivize the block producer to include the Transaction in a block and deter sybil attacks
Authenticator: A digital signature
Entropy: A Nonce (i.e. a random number) to prevent replay protection
type Transaction interface {
GetPublicKey() PublicKey # Cryptographic identifier of sender account; must be the signer
GetSignature() Signature # Digital signature of the transaction
GetMsg() Message # The payload of the transaction; Unstake, TestScore, etc.
GetFee() Big.Int # The number of tokens (uPOKT) used to incentivize and pay for the execution
GetNonce() Big.Int # Entropy used to prevent replay attacks; upper bounded
}
3.8.2 Evidence
Evidence is similar to Transactions in creation, structure and handling, but its production and affects are limited based on the actor's role.
For example, only Validators are eligible to submit and are affected by DoubleSign evidence. Only Servicers are effected by the results of a ClientSideChallenge evidence. Only Fishermen are effected by the results of evidence that may challenge by the results of its TestScores (e.g. RegradeServicer)`.
Evidence is a protection mechanism against faulty or malicious consensus participants, but may extend to other protocol actors as well. The full list of types of Evidence will be defined over time, but will often result in the burning of the actor's stake if proven true.
type Evidence interface {
GetMsg() Message # Payload of the evidence; DoubleSign, TimeoutCert, ClientSideChallenge, etc.
GetHeight() Big.Int # Height at which the evidence was collected and submitted
GetAuth() Authenticator # Authentication of evidence, can be a digital signature or certificate
}
3.8.3 Autonomous
Autonomous state change operations are performed by the protocol according to specific lifecycle triggers linked to consensus. These operations include rewarding block producers, distributing relay rewards, etc.
3.9 Governance Protocol
Though most off-chain governance specification is included in Pocket Network's Constitution, the Utility Module’s Governance Protocol defines how the DAO is able to interact with the on-chain protocol on a technical level.
3.9.1 Parameter Updates
The Access Control List (ACL) is the primary mechanism that enables live parameter configuration. Specifically, the ACL maintains the "feature switches" that allow active modification of the behavior of the protocol without forks. The ACL also maintains the account(s) permissioned to modify said parameters. A value can be modified by a ParamUpdateMsg from the permissioned owner of that parameter.
type ParamChangeMsg interface {
GetAddress() Address # Address of sender & signer; must be permissioned through ACL
GetParamName() String # The name of the parameter being updated
GetValue() any # The new value of the parameter being modified
GetMemo() *String # Explanation (or URL) of why the change was made
}
3.9.2 DAO Treasury
In addition to parameter changes, the DAO is able to burn or transfer from a specified DAO Module Account. In practice, this Module Account is used as the on-chain Treasury of the DAO, the limitations and specifics of which are maintained in the DAO 1.0 Constitution document.
type DAOTreasuryMsg interface {
GetSrcAddress() Address # The sender of the funds; must be permissioned through ACL
GetDstAddress() *Address # OPTIONAL; the receiver of the funds if applicable
GetOperation() DAOOp # The identifier of the operation; burn or send
GetAmount() Big.Int # The operation is executed on this amount of tokens
GetMemo() *String # Explanation (or URL) of why the reasoning for the fund transfer
}
3.9.3 Policing
As the only permissioned actors in the network, Fishermen are subject to individual burns, pauses, or removals initiated by the DAO. Usages of this message type are a result of the off-chain monitoring mechanisms described in the Fisherman Protocol section of the document. The specifics and limitations of usage of this message type is detailed in the DAO 1.0 Constitution.
type PolicingMsg interface {
GetAddress() Address # Address of sender & signer; must be permissioned on ACL
GetPoliced() Address # Address of the policed actor
Operation() DAOOp # Identifier of the operation; burn, pause, remove, etc
GetAmount() Big.Int # Amount of tokens (if applicable)
GetMemo() *String # Explanation (or URL) of the issue
}
Slashing Details
The minimum stake at launch required to become a Service Node is 15,000 POKT. This minimum stake also allows Service Nodes to participate in PoS consensus. If a Service Node stake falls below the minimum amount through serving incorrect data or incorrect block validation, 20% of the minimum stake for that Service Node will be slashed and jailed. If a Service Node submits a fraudulent Relay batch, 100% of their stake will be slashed. The initial amount of POKT needed to stake as a Service Node is not dynamic, but can be raised or lowered by the Pocket DAO to ensure a stable barrier to entry.
Once the initial costs of a Service Node are covered, the only additional cost is electricity and bandwidth for providing the computing power to complete Relays. Marginal costs for Service Nodes are extremely low and increase linearly as work increases.
SeanMcOwen
commented
1 year ago
The following are etc materials that need to be organized into the correct structures:
TBD (Stuff to Later Categorize)
SLA
3.2.2 Network SLA (Service Level Agreement)
Servicers are paid proportionally to how well their Relay responses meet the standards of the Network SLA. A
Relayis an abstraction of a request/response cycle with additional security guarantees when interacting with Web3 resources. The quality of a service is measured by:Since the Fisherman may not necessarily be in the same GeoZone as the Application & Servicers, the Latency will onus will be on them to normalize the TestScores The Fisherman
3.2.3 Report Cards & Test Scores
A
TestScoreis a collection of samples by a Fisherman of a Servicer, based on the SLA criteria outlined above, throughout the duration of a Session.A
ReportCardis the logical aggregation of multipleTestScoresover an Actor's registration lifetime.3.2.4 Volume Estimation
The Application's Web3 usage volume is estimated through probabilistic hash collisions. This enables a concise proof of probabilistic volume, without requiring compute or memory intensive storage and aggregation. Similar to Bitcoin's Difficulty, a
RelayVolumeDifficultygovernance parameter will be used to determine the "difficulty", and how relay counts must be estimated.Each relay can be viewed as an independent Bernoulli Trial that is either a volume applicable relay or not. A geometric distribution can be built of the number of relays that need to be serviced until an applicable relay is made. For example, if a SHA256 hash algorithm is used and
RelayVolumeDifficultyrepresents 3 leading zeroes, the hash of eachconcat(SignedRelay, SignedRelayResponse)above0x000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFwill not be applicable for relay rewards. However, any hash below the target will receiveRelayVolumerewards proportional to the likelihood of the hash. For example,0x000FFF...would be estimateRelayVolumerelays,0x0000FF...would e estimated to 16*RelayVolume, etc...A the end of each Session, the volume applicable relays are sent to the Fisherman for validation and salary distribution.
3.3 Fisherman Protocol Ignored for Now
Stake Burning
Application stake burn is a necessary mechanism to ensure economic equilibrium at network maturity by balancing POKT inflation and deflation.
AppBurnPerSessionis a governance parameter that will dictate the amount of POKT burnt for every session an Application initiates, andAppBurnPerRelaywill govern the amount of POKT burnt based on the amount of work (i.e. number of relays serviced) Servicers provided to the Application throughout the session. Given that the Application's stake will decrease with every session, new rate limiting parameters, dictated viaMaxRelaysPerSession, will be set at the start of each new session.As of updating this document, these governance parameters are expected to be 0 at the time of launching the next version of the network. More detailed tokenomic models will follow in future iterations of the specifications.
3.7.3 Pool
A Pool is a special type of Account that is completely autonomous and owned by the network. POKT can be burnt, minted and transmitted to a Pool at the protocol layer at the time of state transition (after a block is validated) without explicit transactions. Pools can be used for tasks such as fee aggregation, reward distribution and other operations based on state machine changes.
3.8 State Change Protocol
There are two categories of state changes in Pocket Network that may be included in a block:
3.8.1 Transaction
Transactions are discrete state change operations executed by actors or accounts. The structure of a Transaction includes, at a minimum:
3.8.2 Evidence
Evidence is similar to Transactions in creation, structure and handling, but its production and affects are limited based on the actor's role.
For example, only
Validatorsare eligible to submit and are affected byDoubleSignevidence. OnlyServicersare effected by the results of aClientSideChallengeevidence. OnlyFishermenare effected by the results of evidence that may challenge by the results of its TestScores (e.g.RegradeServicer)`.Evidence is a protection mechanism against faulty or malicious consensus participants, but may extend to other protocol actors as well. The full list of types of Evidence will be defined over time, but will often result in the burning of the actor's stake if proven true.
3.8.3 Autonomous
Autonomous state change operations are performed by the protocol according to specific lifecycle triggers linked to consensus. These operations include rewarding block producers, distributing relay rewards, etc.
3.9 Governance Protocol
Though most off-chain governance specification is included in Pocket Network's Constitution, the Utility Module’s Governance Protocol defines how the DAO is able to interact with the on-chain protocol on a technical level.
3.9.1 Parameter Updates
The Access Control List (ACL) is the primary mechanism that enables live parameter configuration. Specifically, the ACL maintains the "feature switches" that allow active modification of the behavior of the protocol without forks. The ACL also maintains the account(s) permissioned to modify said parameters. A value can be modified by a
ParamUpdateMsgfrom the permissioned owner of that parameter.3.9.2 DAO Treasury
In addition to parameter changes, the DAO is able to burn or transfer from a specified DAO Module Account. In practice, this Module Account is used as the on-chain Treasury of the DAO, the limitations and specifics of which are maintained in the DAO 1.0 Constitution document.
3.9.3 Policing
As the only permissioned actors in the network, Fishermen are subject to individual burns, pauses, or removals initiated by the DAO. Usages of this message type are a result of the off-chain monitoring mechanisms described in the Fisherman Protocol section of the document. The specifics and limitations of usage of this message type is detailed in the DAO 1.0 Constitution.
Slashing Details
The minimum stake at launch required to become a Service Node is 15,000 POKT. This minimum stake also allows Service Nodes to participate in PoS consensus. If a Service Node stake falls below the minimum amount through serving incorrect data or incorrect block validation, 20% of the minimum stake for that Service Node will be slashed and jailed. If a Service Node submits a fraudulent Relay batch, 100% of their stake will be slashed. The initial amount of POKT needed to stake as a Service Node is not dynamic, but can be raised or lowered by the Pocket DAO to ensure a stable barrier to entry.
Once the initial costs of a Service Node are covered, the only additional cost is electricity and bandwidth for providing the computing power to complete Relays. Marginal costs for Service Nodes are extremely low and increase linearly as work increases.