The maxCodeSize parameter

Compatibility with the Core Ethereum JSON-RPC API

[P] JRPC-007: Enterprise Ethereum clients SHOULD implement [[JSON-RPC-API]] methods to be backward compatible with the definitions given in version e8e0771 of the Ethereum JSON-RPC API reference [[!JSON-RPC-API-5bdf414]], unless breaking changes were made and widely implemented for the health of the ecosystem. For example, to fix a major security or privacy problem.

[C] JRPC-015: Enterprise Ethereum clients MUST provide the capability to accept and respond to JSON-RPC method calls over a websocket interface.

[C] JRPC-040: Enterprise Ethereum clients MUST provide an implementation of the debug_traceTransaction method [[debug-traceTransaction]] from the Go Ethereum Management API.

[C] JRPC-050: Enterprise Ethereum clients MUST implement the [[!JSON-RPC-PUB-SUB]] API.

[P] JRPC-070: Enterprise Ethereum clients implementing additional nonstandard subscription types for the [[!JSON-RPC-PUB-SUB]] API MUST prefix their subscription type names with a namespace prefix other than eea_.

Extensions to the JSON-RPC API

[P] JRPC-080: Enterprise Ethereum clients must not use the prefix eea_ for the names of [[JSON-RPC]] methods that are not defined by this specification.

[P] JRPC-030: The eea_sendTransactionAsync, eea_sendTransaction, eea_sendRawTransactionAsync, and eea_sendRawTransaction methods MUST respond with a [[JSON-RPC]] error response when an unimplemented private transaction type is requested. The error response MUST have the code -50100 and the message Unimplemented private transaction type.

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -50100,
    "message": "Unimplemented private transaction type"
  }
}

[P] JRPC-035: If a restricted private transaction is requested with values for both the privateFor and privacyGroupId parameters, Enterprise Ethereum clients MUST return an error. The error response MUST have the code -50100 and the message Invalid private transaction parameters.

eea_getPrivateTransactionReceipt

The receipt is not available for pending transactions.

Permissioning Smart Contract

It is based on a chain deployment architecture where permissioning is split into permissioning management, handled by one or more permissioning contracts on the Enterprise Ethereum blockchain, and permissioning enforcement, handled by the Enterprise Ethereum client based on information provided by the permissioning contract.

[P] PERM-300 permissioning contracts provided by an Enterprise Ethereum client SHOULD be certified as conforming to EthTrust Security Level 1, version 1 [[!EthTrust]].

[P] PERM-330 permissioning contracts provided by an Enterprise Ethereum client SHOULD be certified as conforming to EthTrust Security Level 3, version 1 [[!EthTrust]].

Interface
[
  {
    "name": "connectionAllowed",
    "stateMutability": "view",
    "type": "function",
    "inputs": [
      {
        "name": "sourceEnode",
        "type": "string"
      },
      {
        "name": "source",
        "type": "string"
      },
      {
        "name": "sourceEnodePort",
        "type": "uint16"
      }
    ],
    "outputs": [
      {
        "name": "result",
        "type": "bool"
      }
    ]
  },
  {
    "type": "event",
    "name": "NodePermissionsUpdated",
    "inputs": [
    {
      "name": "addsRestrictions",
      "type": "bool",
      "indexed": false
    },
    {
      "name": "addsPermissions",
      "type": "bool",
      "indexed": false
    },
    {
      "name": "enodeId",
      "type": "string",
      "indexed": false
    },
    {
      "name": "source",
      "type": "string",
      "indexed": false
    },
    {
      "name": "port",
      "type": "uint16",
      "indexed": false
    },
    {
      "name": "raftport",
      "type": "uint16",
      "indexed": false
    },
    {
      "name": "orgId",
      "type": "string",
      "indexed": false
    }
    ]
  }
]
  

Interface
[
  {
    "name": "transactionAllowed",
    "stateMutability": "view",
    "type": "function",
    "inputs": [
      {
        "name": "sender",
        "type": "address"
      },
      {
        "name": "target",
        "type": "address"
      },
      {
        "name": "value",
        "type": "uint256"
      },
      {
        "name": "gasPrice",
        "type": "uint256"
      },
      {
        "name": "gasLimit",
        "type": "uint256"
      },
      {
        "name": "payload",
        "type": "bytes"
      }
    ],
    "outputs": [
      {
        "name": "result",
        "type": "bool"
      }
    ]
  },
  {
    "type": "event",
    "name": "AccountPermissionsUpdated",
    "inputs": [
    {
      "name": "addsRestrictions",
      "type": "bool",
      "indexed": false
    },
    {
      "name": "addsPermissions",
      "type": "bool",
      "indexed": false
    }
    ]
  }
]
  

Protecting data at rest

[P] PRIV-220: Enterprise Ethereum clients SHOULD enable encryption of all data stored by the client.
Since some users will prefer to use a system-wide functionality to do this, a good implementation will support that choice.

Private Transactions

The `privateFrom` and `privateFor` parameters in the `eea_sendTransactionAsync` and `eea_sendTransaction` calls specify the public keys of the sender and the intended recipients, respectively, of a private transaction. The private transaction type is specified using the `restriction` parameter. The only type of private transaction defined as required is Restricted private transactions, where payload data is transmitted to and readable only by the parties to the transaction.

[P] PRIV-010: Enterprise Ethereum clients MUST support restricted private transactions.

Transaction information consists of two parts:

• Metadata, which is the set of data that describes and gives information about the payload data in a transaction. Metadata is the envelope information necessary to execute a transaction.
• Payload data, which is the content of the data field of a transaction, usually obfuscated in private transactions. Payload data is separate from the metadata in a transaction.

[P] PRIV-005: Enterprise Ethereum clients MUST implement the method to return receipts for restricted private transactions.

[P] PRIV-011: Enterprise Ethereum clients MUST use the SHA3-512 algorithm [[!SHA3]] to calculate hashes of the payload in restricted private transactions.

[P] PRIV-020: Enterprise Ethereum clients MUST encrypt payload data when stored in restricted private transactions.

[P] PRIV-030: Enterprise Ethereum clients MUST encrypt payload data when in transit in restricted private transactions.

[P] PRIV-050: Enterprise Ethereum clients MAY encrypt metadata when in transit in restricted private transactions.

[P] PRIV-060: Nodes that relay a restricted private transaction, but are not party to that transaction, MUST NOT store the payload data.

[P] PRIV-070: Nodes that relay a restricted private transaction, but are not party to that transaction, SHOULD NOT store the metadata.

[P] PRIV-080: The implementation of the eea_sendTransactionAsync, eea_sendTransaction, eea_sendRawTransactionAsync, or eea_sendRawTransaction methods (see Section ) with the restriction parameter set to restricted, MUST result in a restricted private transaction.

[P] PRIV-180: Enterprise Ethereum clients SHOULD be able to extend the set of parties privy to a private transaction (or forward the private transaction in some way).

[P] PRIV-190: Enterprise Ethereum clients SHOULD provide the ability for nodes to achieve consensus on their mutually private transactions.

Nodes

[C] NODE-010: Enterprise Ethereum implementations MUST provide the ability to specify at startup a list of static peer nodes to establish peer-to-peer connections with.

[C] NODE-020: Enterprise Ethereum clients MUST provide the ability to enable or disable peer-to-peer node discovery.

[P] NODE-090: Enterprise Ethereum clients SHOULD implement transaction ordering according to the "by Price and by Nonce" algorithm, sorting transactions by price while respecting the nonce ordering for each account.

[P] NODE-095: Enterprise Ethereum clients MUST specify explicitly and precisely in documentation any transaction ordering logic that is different from that recommended in NODE-090.

Ethereum Accounts

• A user is a human or an automated process interacting with an Enterprise Ethereum blockchain using the Ethereum JSON-RPC API. The identity of a user is represented by an Ethereum account. Public key cryptography is used to sign transactions made by the user so the EVM can authenticate the identity of a user sending a transaction.
• An Ethereum account is an established relationship between a user and an Ethereum blockchain. Having an Ethereum account allows users to interact with a blockchain, for example to submit transactions or deploy smart contracts. See also, wallet.
• Roles are sets of administrative tasks, each with associated permissions that apply to users or administrators of a system, used for example in RBAC permissioning contracts.

[P] PART-010: Enterprise Ethereum clients MUST provide the ability to specify a list of accounts that are permitted to transact with the blockchain.

[P] PART-015: Enterprise Ethereum clients MUST be able to verify that accounts are present on the list required by PART-010 when adding transactions from the account to a block, and when verifying a received block containing transactions created by that account.