FIO Layer 2 is a concept which introduces an off-chain framework, which enables FIO Protocol users to exchange messages between each other without the need to store those messages on-chain.
Messages which are candidates for this approach are:
Public Address Mappings, FIO Requests and OBT records. Even though these records are stored on-chain today, there is already an initiative on the Roadmap to consider moving it off-chain for performance reasons and another one to consider expanding the size of the associated content.
Request for Signature. Initial feedback received from wallets indicates a preference to store such requests off-chain.
Public Address Request and Friend List functionality. During the design of FIP-5, the requirement to store data on-chain created significant complexities. If the data can recorded anonymously off-chain, the FIO Privacy solution may be much simpler.
Push notifications. Off-chain messaging solution would likely make it simpler to develop a push notification mechanism for wallets.
Secure messaging. Ability to exchange messages between FIO Addresses has long been considered for development. Recently a community member has submitted a FIP-24: Secure Message Standard, which contemplates a solution similar to Layer 2 described here.
Messages which are not candidates for this approach are:
Token transfers - since FIO Chain’s main purpose is not payment solution and due to the complexity associated with a payments on L2, token transfers are not a good fit for L2.
FIO Domain/Address registration - since the FIO Private key which owns a FIO Address or Domain is critical to authenticate the L2 message, and because it involves a payment transaction, FIO Domain/Address registration are not a good fit for L2.
Core blockchain transactions (voting, proxying, account management, etc.)
Similar to other Layer 2 solutions, the benefits of this approach include:
Performance - since transactions do not need to be recorded on-chain, they can be recorded and read faster and are not subject to throughput or size constrains, typical for on-chain transactions. Potentially overlaps with https://fioprotocol.atlassian.net/browse/WP-119
Cost - off-chain transactions can be significantly cheaper or free.
Privacy - off-chain transaction can be recorded with a higher-level of privacy. Specifically, the sender of the transaction does not need to be uniquely identified as is the case for on-chain transaction.
Upgradability - the message standard can be more easily upgraded as it does not require core blockchain modifications.
The solution would consist of nodes which would relay messages between FIO Protocol users.
The message would be routed to recipient using FIO Addresses.
Recipient would fetch the message using their FIO Address or a search index contemplated in FIP-5 to further enhance privacy.
The messages would be signed with FIO Private Key which owns sender’s FIO Address.
The recipient would fetch the FIO Public Key which owns the sender’s FIO Address from the FIO Chain and use it to cryptographically validate that the message was created by the owner of the private key which owns the sender’s FIO Address.
The message could be further encrypted using Diffie-Hellman Key Exchange scheme similar to how FIO Request content is encrypted today.
What is the incentive to run an L2 node and who will run it?
Anyone - because all messages are signed by the private key of the sender, there is no trust required to run a node. Therefore anyone could do it. The incentive to do it could be:
Part of FIO Chain fees could be redirected to L2 node operators.
Nodes could be ran by integrators (wallets/exchanges) as they have an incentive to service their customers.
Block Producers - block producers already have an incentive to run FIO Chain infrastructure and that L2 node could be part of it.
By definition blockchains are highly available and censorship resistant, because the data is securely replicated across many nodes.
What is the optimal design for L2 nodes?
Non-replicated - allow FIO Address owner to specify which node to use to send or receive L2 messages. Only that node would contain the relevant content. Similar approach has been described in FIP-24.
The downside of this approach is that:
Data can be irreversibly lost if the node is lost.
Data is not accessible if node is down or is being censored.
See related discussion regarding Request for Signature.
Replicated - the messages are simultaneously stored on and are accessible by querying any node.
The downside of this approach is that:
High overhead of having to maintain and sync messages across multiple nodes.
Today most FIO Chain transactions have an on-chain cost. This is intended to deter, but not prevent spam. There is already an initiative on the Roadmap to consider solutions to FIO Request spamming, which have already been reported. This issue is significantly larger if the cost of transmitting a message is free. An attacker could easily send millions of messages intended to spam users or to make the service unusable.
How is spam mitigated?
Build functionality at the node-level to combat spam using methods such as:
FIO Address reputation
Allow recipients to flag messages as spam
Rate-limiting
See related discussion regarding Request for Signature.