HOW DOES IT WORK?
The goal of Solcial’s development is to give users with a social media platform experience that is as near to Web2 as feasible while still making use of Web3 technology.
In every blockchain-based network, user fees are a potential roadblock. Solcial is developing a peer-to-peer (P2P) layer rooted in Solana and built on top of libp2p that serves content (feeds, likes, etc.) via self-hosting and peer replication in order to minimize user costs for non-token related transactions while ensuring privacy and consensus.
To support tens of thousands of concurrent peers, we have built a new sort of node called Beacon Nodes that has the same external protocol as a conventional desktop or mobile app. Because all user material is kept on IPFS and made accessible to other users through a P2P layer rather than censorable servers or gateways, Beacons act as a kind of backup for users' content when its authors go offline.
Introduction
Solcial’s internal workings provide unique censorship resistance properties while maintaining reasonable data exchange performance, as described in this first post.
Despite the fact that this paper is geared at a more technical readership, we believe that non-technical Solcial users will still find value in the technology underlying the protocol, which this article explains.
Network Topology
Using a modified version of the HyparView1 protocol, Solcial nodes connect via the internet to establish an overlay network.
Log2(N+1)+1 is the number of active peers that each node keeps track of, based on an estimate of the network’s total size. As the number of users increases, the blockchain’s N value is updated to reflect the most recent number of accounts that have been created. Nodes interact directly with the active peers, which have reliable, bidirectional, and durable connections, during gossip or any other p2p activity. Backup peers are kept on each node in the event that an active peer disconnects or ceases to respond, and this list has a size of 6*(Log2(N) + 1). QUIC2 and NOISE encryption are used by libp2p3 to establish connections between active peers.
There are three ways to get over NAT, and the one that is utilized depends on the peer’s network configuration. To avoid NATs, the first option is to switch over to IPv6 whenever feasible. However, only around 40% of the internet is now on IPv64, according to statistics.
Using the libp2p identity protocol, which requests other nodes in the network for the visible IP address of our computer, is the backup strategy. A NAT-based peer’s IP has already been registered to that machine’s router; but, in the event that this does not work, we must resort to the third and most dependable (but also most costly) alternative.
When two NATs are involved, the third option is to utilize an intermediary node that acts as an intermediary between the two peers and retransmits the packets. Beacon nodes and certain peers with public IPs that choose to be relays may adopt this function. Beacon nodes will be discussed in further detail in the following sections.
Overlay Membership
The Solcial peer-to-peer network will be omitted from the HyparView network overlay if a user’s public key is not registered on the chain.
The /solcial/public topic is used by all peers who want to join the Solcial p2p network to send a JOIN message to one of the bootstrap nodes. One of the changes we made to the original study was to add subjects to HyparView.
JOIN requests from peers will first verify that the multihash exists on the chain and is associated with a Solcial account, then the node will send a FORWARDJOIN message to one of its active peers with an active random walk set to 3, and they in turn will propagate that message to all their active peers, increasing the current hop number by one until it reaches 3 hops. DDoS assaults on bootstrap nodes may be mitigated, and the connectivity between nodes can be distributed and randomized as much as possible using this strategy.
The first JOIN requestor will get a NEIGHBOR message from any node that is within three hops of the initial JOIN receiver.
Each node will broadcast a SHUFFLE message every 15 seconds to a randomly selected active peer, along with a randomly selected sample of its active and passive peers, and will set the random walk length of this message to 4. That way, when a peer becomes unresponsive or actively disconnects, all of the remaining peers have the most up-to-date information available to them for network repair reasons.
Efficient Gossiping
Only peers who are actively disseminating messages may do so. There are cycles in the connection graph connecting nodes that create an overlay network on top of the public internet. First, we need to reduce the propagation of duplicate messages between peers, and then we need to determine the most efficient path for messages to take on the network.
Epidemic Broadcast Trees8 is a method that divides peers into groups of eager-push nodes and lazy push nodes and then builds a minimal spanning tree between them. Messages are immediately transmitted to eager-push nodes when they are received.
Lazy push nodes get a batch of message IDs viewed by the current node on a regular basis, every 500ms, in lazy push nodes. The connection is rebuilt (GRAFT) and the active-push state is restored if a node notices that a message id in the lazy-push batch has not been received from its upstream parent node. In the event that one of the nodes goes down and creates fragmented graphs, this is the least spanning tree repair strategy. A GRAFT message restores the whole network to full operation
Lazy-Pushes are created whenever an active node receives a copy of a previously received message from that node, and the connection to that node is considered a cycle in the graph.
It’s also a good idea to cut an active connection and replace it with a lazy one if we see that the number of hops it took for a message from a lazy node to reach us is fewer than four. The broadcast tree optimization approach is based on this.
Content Dissemination
Solcial users' CIDs are used to identify the IPFS Bitswap9 messages that are gossiped via the protocol outlined in the preceding sections. To further understand how Solcial uses Bitswap and IPFS, let’s take a look at a user profile first.
A profile index is a unique identifier for each and every one of the network’s users. CIDs for the most recent iterations of its material are referenced in this index. The index is a CRDT with an Eventually Consistent Sequence (ECS) that keeps a record of all the actions taken on the account.
Peers accept only those elements in the profile index that are signed using the account owner’s private key and may be thought of as a linked list in which each item references to the CID of the item before it.
An IPFS PB-DAG10 object is broadcasted to the /solcial/content HyparView overlay topic for an entry like that. By recursively searching connected CIDs, users may access the whole account history and content.
Any peer who receives this object must first verify that the content’s signature matches the author’s public key. The sender peer is permanently banned from the current node if the signature verification fails. The material spreads to all other peers who are interested in content published by this account if the signature validation is successful.
It is recorded in the author’s log when a CID is received from a peer. The profile’s current state is made up of all of the author’s actions.
It’s the default setting for each node to pin and seed only material from its own account and the accounts of people it knows. The beacon nodes we’re creating as part of our infrastructure are similar to typical user peers in that they’re interested in all material, but they also act as a type of Social-specific IPFS pinning service for all content in the event that all existing seeders go down. These are nodes that everyone can relate to. While the network may operate without them, they provide an additional layer of content accessibility.
Read Access
IWANT and IHAVE Bitswapping messages to the /solcial/content topic with the CID of the top-level root index of the account may be broadcasted to recursively request all connected CIDs on the Solcial p2p overlay.
Sending a HEAD message to /solcial/sync and waiting for other peers who are seeders (including beacon nodes) to reply with the CID of the most recent material they are aware of is how an account’s initial sync or most recent entries are obtained. Queries to the Solana blockchain perform the translation between user handles and user public keys.
Previous entry fields may be utilized for dispute resolution and picking the most recent entry.
Privilege Content Access
Tier-1 and Tier-2 subscription feeds are examples of material that is exclusively meant for a small number of people. Prior to being published, all of those posts have been encrypted using an asymmetric AES-256 key. The hash of the key is included in the original post’s content information.
During the libp2p handshake, the key is distributed to a random selection of eligible peers across the NOISE encrypted channel. When a post is published, the author has the option of participating in this key exchange mechanism, but they don’t have to do so if they consider their information is particularly sensitive. The GETKEY message is sent to the /solcial/keyexchange overlay topic when an eligible user wishes to interpret the content.
By querying the blockchain, any peers with that key that are online will authenticate the user’s eligibility for accessing the content by determining whether or not the user has the tokens necessary to do so. A direct quic/noise connection, which bypasses the gossip protocol, is used to transfer the key after successful verification.
