This section describes the network protocol between FinP2P nodes (based on LibP2P), and the digital securities API calls that each node must be able to generate and respond to.
Securities API calls
The specific API calls will be published in the coming weeks, the main API calls will cover:
...
If a node is implementing the network protocol, and able to send/receive those APIs, they will be technically able to join the network.
Overview of FinP2P Network Protocol
The FinP2P Network interface abstracts the communication between multiple distributed FinP2P Nodes by exposing a set of primitives and flow specifications.
FinP2P Network is layered on top of the open source project LibP2P and leverages most of its building blocks, extending and enhancing when needed.
Governance
FinP2P is a decentralized network with a trusted Identity system. For this identity to be trusted by all members of the network, a governance function is defined.
...
Every node in the network has to be certified by one of the Governance nodes.
Every Governance node has to be certified by one of the Founding nodes.
Governance Functions
Generate Organization Identities: The Governance Node is responsible to validate Organizations and generated their FinID ( FinP2P Global Identity )
Rendezvous Services: Governance Nodes are located at well known addresses. New Organizations joining the network will contact those nodes for bootstrapping and join the FinP2P network
Trusted source of Peers: Governance Nodes keep a registrar of Network members to answer to Discovery requests.
Other function will be added in the future.
Primitives
FinP2P is built on top of a set of extensible primitives:
Identity: Every participant of the FinP2P network can be identified and its identity proven.
An Organization can create identities to any resource it manages. For more information on identities, see FinP2P Data ModelAdvertising and Discovery: Services are advertised by Organization. A Node requesting a specific service can send a Discovery request to get the addresses of the Nodes providing the requested service.
P2P, Broadcast and PubSub: Communication between Nodes is managed by the type of service they are consuming or providing.
P2P -- Request / Response: This type of communication is known as synchronous.
Publish / Notify paradigms: Asynchronous communication.
Broadcast: This type of request sends a question to the network and expects multipleanswers for validation.
Built In Encryption and Privacy: Encrypted P2P communication. ACL based broadcast. And more
Identity
Each profile in the network is identified by a unique ID called FinID. The network uses FinIDs to execute various actions across the platform.
...
The identity is generated when a new profile is created on the network. for organisations, the identity is generated by the Governance node that adds them to the network. For all other profiles, the identity is generated by their Primary node.
Advertisements and Discovery
Implementation: The following LibP2P protocols are in consideration for this feature
...
Node Identity
Node Address
Supported Service
Version
...
Joining the FinP2P network
After receiving an Identity, participating Organizations join the network dynamically.
...
The preliminary steps are:
Registration
At join time, the organization has to register its cluster to the FinP2P network. The registration is done by advertising the Organization Identity, Node Address and Capabilities.
Address
Implementation: The following LibP2P specification is considered for addressing
* Addressing: https://docs.libp2p.io/concepts/addressing/
The Node address has to be a public resolvable DNS name, or a set of public IPs addresses. Advertising a private address will prevent other nodes from communicating with it.
Capabilities
The capabilities information lists supported FinP2P protocols and communication details.
This specification will list the set of mandatory and optional protocols an implementation has to support.
Advertisements
Each organization MUST advertise its capabilities and resources it wants to share. Failing to do so will prevent other organizations from communicating with it.
...
Capabilities
Capability advertisement is fundamental for FinP2P protocol. Any change of version, address and supported protocols must be announced to the network as soon as possible. FinP2P modules are well aware of most of the capabilities changes and this update can happen automatically.
An Organization MUST at least advertise the mandatory protocols supported by its nodes.
Resources
Each resource defined in the system has a resourceid attached to it. The resource ID is a unique identifier that aims to provide the exact location of the resource in the network.
...
An example of a resource is an Asset managed by an Organization:
Managed Assets
Assets managed by an organization are resources that an organization can share with others.
...
With the resource ID, allowed Organizations can send direct ( P2P ) requests to get the resources up to date information.
...
Advertise / Subscribe / Publish Flow
Implementation: The following Pub/Sub LibP2P specification is considered to implement FinP2P Pub/Sub:
...
...
Subscribe to Topic
...
Publish Topic Data
...
P2P and Broadcast requests
Organization nodes rely on the FinP2P API to communicate with the network. Internlay, the FInP2P abstractions translate the API to network requests.
This specification defines 2 types of requests: Peer-to-peer and Broadcast requests.
Peer-to-peer Requests
The most common case of a P2P communication is when a request has to be executed by a specific Organization.
Some of the uses cases of P2P requests are:
Asset Transaction
One of the flows for P2P is when Organization A wants to transact with assets managed by Organization B. In this case Org A MUST directly contact the Primary Node of Organization B. Using the data collected from the Discovery protocol and the Assets advertised by Org B, the FinP2P layer has all the information to send the asset transaction request to the Primary Node Address of Org B.
...
The Asset Transfer response is a signed notification from the Asset Manager Primary Node that the request was fulfilled. The signed Response payload includes all the details of the asset transaction and metadata related to the Recorded Distributed Ledger Transaction.
This information is then recorded on Organization A Distributed Ledger to keep records of Asset Transaction receipts. The receipt can be verified at any time by the holder.
Private Data Queries
On this P2P flow, an Organization A is requesting access to Organization’s B Private Data using an advertised resource ID.
...
FinP2P maintains a caching copy of ACL information to prevent DDOS from non allowed organizations. Any change in the ACL will be broadcasted to the interested parties.
Private Data Query Flow: User information during asset transfer
Implementation: The following User data messaging specification is considered for implementing User data sharing in FinP2P
VIMS-101 Messaging Standard: https://intervasp.org/
...
During the transfer flow, Org B has to get access to the seller and buyer to validate the transaction with the regulations assigned to the asset. At this time, if no information about OrgA-user-1 and OrgA-user-2 is available for Org B, it sends a P2P Private Data Request to Org A with the user’s IDs. If Org B is “allowed” to get this type of information, Org A response includes the requested information for Org B to continue the Transfer request.
...
Broadcast Request
A broadcast request is sent to the network when multiple nodes can fulfill the request. Broadcast requests can be sent to the global network, to a specific group of nodes or to a specific group of Primary nodes sharing the same underlying Distributed Ledger.
...
The payload of the request is signed by the sender's Identity and it may also be encrypted to prevent forwarding nodes to get access to sensitive information.
User Balance Broadcast Request
Scenario: Organization A has two users; orga:user:1 and orga:user:2. Those users are owners of assets managed by other organizations and Distributed Ledgers. In order to get a current asset balance for those users, a broadcast message is sent to the Primary Nodes of the Distributed Ledger where the asset is managed.
The broadcast request is signed by Organization A Primary Node and is sent to all primary nodes of the same Distributed Ledger. The request includes details of the user and the asset.
...
Receipt validation Broadcast Request
An organization holding an asset transfer receipt can verify its validity by broadcasting the receipt metadata. Any Node with access to the Distributed Ledger can verify the metadata transaction and respond.
...