Baseline Standards Requirements based on L2 Baseline 2020 Summit outcomes

[Therecanbeonlyone1969]

Below is the first collection of Baseline Standards Requirements organized by impacted standard area based on the 2020 Baseline Summit WG on Scaling. Note, that the requirements touch all areas but are not comprehensive as to the entire protocol:

Definitions:

• NFR = Non-Functional Requirements
• FR = Functional Requirements

#	Component	Requirement Category	Requirement Type	Requirement
1	Communication	Message Delivery	NFR	API gateway MUST support high-operational throughput -- at least 1000 tps
2	Communication	Authentication & Authorization	NFR	Operator MAY employ a centralized solution for baseline identities/accounts/workgroups
3	Communication	Authentication & Authorization	NFR	Operator MUST synchronize workgroup entities and their accounts to the Baseline Global Phone book
4	Communication	Authentication & Authorization	NFR	Operator MUST synchronize workgroup entities and their accounts to the Baseline Global Phone book
5	Communication	Authentication & Authorization	NFR	Operator MAY add additional operator specific metadata to synchronized Baseline Global Phone book records
6	Communication	Authentication & Authorization	NFR	Operator MUST NOT have the ability to change, update or delete Baseline global phonebook records
7	Communication	Messaging	NFR	In the single operator model, an operator MAY use centralized messaging solutions that meet at least the scaling requirements for the API gateway
8	Communication	Messaging	NFR	In the network operator model, an Operator MUST be able to support more than 1 messaging protocol
9	Communication	Messaging	NFR	In the network operator model, messages MUST be able to be replicated between network participants with low-latency and throughput meeting at least API gateway throughput requirements
10	Communication	Messaging	NFR	Identities of the message sender and recipient MUST be based on validated identifiers from the Baseline Global Phone book
11	Agreement Execution	Business Logic Execution	FR	A Baseline Virtual State Machine MUST be able to perform general computations for state transitions within a workflow step from State A to State B
12	Privacy & Confidentiality	Performance	NFR	If the Operator is allowed to see any type of transaction data, the operator MAY utilize a non-privacy preserving scaling solution for state transition computations such as sidechain, rollup, or state channel
13	Privacy & Confidentiality	Privacy	NFR	If the Operator is allowed to see any type of transaction data, the operator MAY utilize a non-privacy preserving scaling solution for state transition computations such as sidechains, rollups, or state channels
14	Privacy & Confidentiality	Privacy	NFR	If the Operator is allowed to see any type of transaction data and the transaction data will not be used in a tokenization event or in a tokenization event where the token does not exist on an L1/Public DLT, the operator MAY utilize a non-privacy preserving scaling solution for off-chain computation with only minimal cryptographic, privacy-preserving data on L1/public DLT such as a content-addressable hash
15	Privacy & Confidentiality	Privacy	NFR	If the Operator is not allowed to see any type of transaction data, the operator MUST utilize only a privacy-preserving scaling solution
16	Privacy & Confidentiality	Privacy	NFR	If the Operator is not allowed to see any type of transaction data, the operator MAY utilize an anonymity preserving scaling solution
17	Privacy & Confidentiality	Privacy	NFR	If the Operator is not allowed to see any type of transaction data and the transaction data will not be used in a tokenization event or in a tokenization event where the token does not exist on an L1/Public DLT, the operator MUST utilize only a privacy-preserving scaling solution for off-chain computation with only minimal cryptographic data on L1/public DLT such as a content-addressable hash
18	Privacy & Confidentiality	Privacy	NFR	If the Operator is not allowed to see any type of transaction data then and the data is to be used in a tokenization event on an L1/Public DLT, the operator MUST allow for availability of all token related data on the L1/public DLT layer within an L1 finalization time of less than 1 hour
19	Security Considerations	GA/Production readiness (application)	NFR	Baseline Smart Contract system must have defense mechanisms against transactions spamming. At a minimum, a known and validated set of operators with write access and a large operator bond combined with a limit on the number of transaction per block a Baseline smart contract will allow as a slashing condition to disincentivize spamming
20	Communication	Messaging	NFR	A Baseline Messaging protocol MUST ensure message linear sequencing
21	Communication	Messaging	NFR	A Baseline Messaging protocol MUST ensure high-level of message completeness (99.99%) within an operational processing window
22	Agreement Execution	Business Logic Execution	NFR	An operator MUST avoid state dependencies across Baseline implementations or non-interoperable workflows due to technology constraints. Note: If there is a state dependency between baseline transactions on two or more different baseline implementations such as an MSA shared between two baseline workflows on two different stacks, there is no way to ensure consistency of both off-chain and onchain transactions
23	Agreement Execution	Business Logic Execution	FR	An operator SHOULD support multiple deterministic execution frameworks
24	Agreement Execution	Business Logic Execution	FR	An operator SHOULD not allow for cross execution framework state dependencies at the beginning or during the execution of a workflow (instance). Note: There is no direct way to prove the correctness of state from one workflow in another workflow across different execution frameworks because they "do not speak the same language". It would require a translation relay which introduces an additional attack surface and workflow dependency that counterparties cannot control.
25	Agreement Execution	Business Logic Development	FR	Each transaction MUST have the following identifiers by identifier type: Workflow ID (UID) Workflow Instance ID (UUID) -> must be connected to Workflow ID Workflow Step ID (UID) -> must be connected to workflow ID Workflow Instance Step ID (UUID) -> must be connected to Workflow instance ID
26	Agreement Execution	Business Logic Development	FR	Each transaction MUST be associated with a deterministic nonce
27	Agreement Execution	Business Logic Development	FR	A deterministic nonce SHOULD be associated with an Account. Note: There are separate account requirements. An account must have an account number/address (GUUID) An account must have at least one account owner An account may have more than one account owner An account may be associated with the state of a workflow An account may have one or more token balances Account ownership must be cryptographically provable A transaction from an account changes the state of the account
28	Agreement Execution	Business Logic Execution	FR	Transactions for the same workflow instance MUST be deterministically ordered
29	Agreement Execution	Business Logic Execution	FR	"A transaction referring to an account MUST fail if The transaction nonce,n, is not equal to the account nonce plus 1, N+1. The cryptographic signature of the account owner(s) on the transaction cannot be verified The transaction does not have the correct Workflow ID, Workflow Instance ID, Workflow Step ID, Workflow Isnatnce Step ID The transaction is not well-formed based on the requirements of the chosen execution framework
30	Agreement Execution	Business Logic Execution	FR	The unique IDs on a transaction SHOULD be generated by the transaction originator
31	Agreement Execution	Business Logic Execution	FR	If there is a baseline operator network to execute and confirm transactions, the consensus algorithm employed MUST have a time to finality << than the time to finality of the underlying L1/public DLT
32	Agreement Execution	Business Logic Execution	FR	If there is a baseline operator network, the consensus algorithm MAY only order transactions based on the UIDs on the transactions. Note: This would allow different operators in the network to utilize different execution frameworks
33	Agreement Execution	Business Logic Execution	FR	If there is a baseline operator network and it chooses consensus on the execution of a transaction, there MUST be a consensus algorithm on both the order and the correct execution of transactions
34	Agreement Execution	Business Logic Execution	FR	If there is a baseline operator network and it chooses consensus on the execution of a transaction, the network MUST use a common execution framework. Note: If more than one execution framework were chosen, no consensus could be reached on the outcome of a transaction because the state representation is execution framework dependent e.g. Ethereum account state vs. a zk-proof of account state
35	Agreement Execution	Business Logic Execution	NFR	Baseline Scaling solutions MUST have at least the same security assurances as the L1/Public DLT
36	Security Considerations	GA/Production readiness (application)	NFR	The cryptographic primitives of a baseline scaling solution MUST have been audited by a 3rd party
37	Security Considerations	GA/Production readiness (application)	NFR	The cryptographic primitives of a baseline scaling solution SHOULD have passed the NIST Cryptographic Module Verification Program (CMVP)
38	Security Considerations	Data Privacy (information)	FR	If required, a baseline user MUST be able to access their baseline off-chain data from an operator (network) at all times
39	Security Considerations	Data Privacy (information)	FR	A baseline user MUST NOT have write-privileges to baseline off-chain data unless the user is also a baseline operator (single or in a network)
40	Security Considerations	Data Privacy (information)	FR	Baseline off-chain data storage MUST be append-only if it is configured as a P2P or Master-Master replication system

[Consianimis]

Added to Baseline Protocol - Requirements Mastersheet. Issue can be closed.

[Consianimis]

Is this a duplicate of https://github.com/ethereum-oasis/baseline-roadmap/issues/156 ?

[Therecanbeonlyone1969]

Is this a duplicate of #156 ?

@Consianimis ... yes it was the raw data. This one were the refined requirements

[Therecanbeonlyone1969]

not resolved ... keep open to import into standards repo