WEB-SCALE SOCIAL PEER-TO-PEER PROTOCOL
TLDR:
- Binubuo ang Solcial upang mabigyan ang mga user ng experience na mas malapit hangga't maaari sa mga platform ng social media ng Web2, habang sinasamantala ang mga teknolohiya ng Web3.
- Ang isang balakid na kinakaharap ng anumang platform na nakabatay sa blockchain, ay ang user fees. ang Solcial ay gumagawa ng isang peer-to-peer (P2P) layer na naka-angkla sa Solana at binuo sa ibabaw ng libp2p na naghahatid ng content (mga feed, likes, atbp) sa pamamagitan ng self-hosting at peer replication.Ito ay upang alisin ang mga user fees para sa mga operasyong hindi nauugnay sa token habang pinapanatili ang privacy at consensus.
- Nakabuo din kami ng isang espesyal na uri ng node na may parehong external protocol gaya ng karaniwang desktop o mobile app, na may mga karagdagang pag-optimize na idinisenyo upang pangasiwaan ang libu-libong magkakasabay na peer, na tinatawag na Beacon Nodes. Ang mga beacon ay mahalagang hanay ng mga serbisyo sa pag-pin na magpapanatili ng content ng mga user kapag nag-offline ang mga creator at ginawa itong available para sa ibang mga user; lahat ng nilalaman ng user ay naka-store sa IPFS at ina-access sa pamamagitan ng isang P2P layer nang hindi umaasa sa mga censorable na server o gateway.
Introduksyon
Ito ang unang post sa isang serye ng mga tala na naglalarawan kung paano ang mga panloob na gawain ng Solcial protocol ay nagbibigay dito ng mga natatanging katangian ng censorship resistance habang pinapanatili pa rin ang makatwirang pagganap ng palitan ng data.
Network Topology
Ang mga node ay nakikipag-ugnayan sa pampublikong internet, na bumubuo ng isang overlay na network na partikular sa Solcial gamit ang isang binagong bersyon ng HyparView¹ protocol.
Ang bawat node ay nagpapanatili ng isang listahan ng mga aktibong kapantay na may sukat na log2(N)+1 kung saan ang N ay ang tinantyang laki ng buong network. Ang halaga ng N ay kinukuha mula sa blockchain sa pamamagitan ng paghahanap ng bilang ng mga user account na naka-sign up to date, at pana-panahong ina-update habang lumalaki ang bilang ng mga user. Ang mga koneksyon sa mga aktibong kapantay ay stable, bidirectional at paulit-ulit at iyon ang mga node na direktang nakikipag-ugnayan sa kanila sa panahon ng tsismis o anumang iba pang aktibidad ng p2p. Ang bawat node ay nagpapanatili din ng isang listahan ng mga passive peer na may sukat na 6.(log2(N)+1) na ginagamit bilang mga backup na peer kung sakaling madiskonekta o hindi tumutugon ang alinman sa mga aktibong peer. Ang pinagbabatayan na protocol para sa mga koneksyon sa pagitan ng mga aktibong peer ay QUIC² na may NOISE encryption, lahat ay pinapagana ng libp2p³.
Ang NAT traversal ay nakakamit gamit ang tatlong pamamaraan na ginagamit depende sa network circumstances ng peer. Ang unang paraan ay ang paggamit ng IPv6 sa halip na IPv4 hangga't maaari dahil sa kasong iyon ay hindi na kailangan para sa mga NAT, gayunpaman ayon sa mga istatistika ay nasa ilalim lamang ng 40% ng internet ang nasa IPv6⁴.
Ang fallback mechanism ay ang paggamit ng AutoNAT sa pamamagitan ng paggamit ng identity protocol ng libp2p na nagre-request sa iba pang mga node sa network tungkol sa nakikitang address ng aming machine. Ang address na iyon, na pinasimulan ng peer sa likod ng isang NAT, ay nakarehistro na sa kanilang router sa target na makina, gayunman may mga pangyayari na kapag hindi ito gumana ay babalik tayo sa pangatlo at pinaka-maaasahan ngunit mahal na opsyon.
Ang pangatlong opsyon ay ang paggamit ng libp2p circuit relay⁵ protocol na ginagaya ang paggana ng isang TURN⁶ protocol sa pamamagitan ng pagkakaroon ng intermediate node na nagre-relay ng mga packet sa pagitan ng dalawang peer sa likod ng mga NAT. Ang tungkuling ito ay maaaring ipagpalagay ng mga beacon node at ilang mga kapantay na may mga pampublikong IP na nag-o-opt in sa pagiging mga relay na may mga naka-configure na limitasyon. Tatalakayin natin mamaya ang mga beacon nodes sa post na ito.
Peer Identity
Natutukoy ang mga peers gamit ang kanilang public key sa anyo ng isang multihash⁷ na katumbas ng pampublikong susi ng kanilang wallet address sa Solana na nakarehistro sa Solcial on-chain na kontrata.Maipagpapalagay natin na ang isang ibinigay na public peer id ay ang pagkakaroon ng sikretong key ng isang ED25519 keypair.
Ginagamit din ang keypair na ito upang magtatag ng mga encrypted channel para sa lahat ng mensaheng dumadaan sa pagitan ng mga peers, ito rin ang isang paraan upang i-verify ang pagiging tunay ng mga mensahe na maaaring ginawa ng may-ari ng wallet.
Overlay membership
Ang mga peer na may mga public key na hindi nakarehistro sa chain ay hindi papayagang sumali sa HyparView network overlay at sa pamamagitan nito ay awtomatikong hindi kasama sa Solcial na peer-to-peer network.
Ang lahat ng mga peers na gustong sumali sa Solcial p2p ay magpapadala ng isang JOIN message sa isa sa mga bootstrap node (ang ilan sa mga bootstrap node ay mga beacon node din) sa /solcial/public topic. Ang introduksyon ng mga topic sa HyparView ay isa sa aming mga pagbabago sa aming original papers.
Anumang node na tumatanggap ng kahilingan sa JOIN mula sa isang peer ay unang magbe-verify na ang multihash ay umiiral sa chain at nauugnay sa isang Solcial account, pagkatapos ay magpapadala ito ng isang FORWARDJOIN message sa isa sa mga aktibong peer nito na may active random set to 3, sila ang magpapalaganap ng mensaheng iyon sa lahat ng kanilang aktibong peer, na tataas ng isa ang kasalukuyang numero ng hop hanggang umabot ito ng 3 hops. Ito ay isang pagpapagaan para sa mga pag-atake ng DDoS laban sa mga bootstrap node, pati na rin ang isang epektibong pamamaraan ng desentralisasyon upang maikalat at i-randomize ang pagkakakonekta sa pagitan ng mga node hangga't maaari.
Anumang node na nasa loob ng 3 hops ng paunang JOIN receiver ay magpapadala ng mensahe ng NEIGHBOR sa inital JOIN requestor na magtatatag ng aktibo at paulit-ulit na koneksyon sa pagitan nila.
Kada 15 segundo ang mga node ay magbo-broadcast ng isang SHUFFLE na mensahe sa isang random na aktibong peer na may random na sample ng mga aktibo at passive na peer nito at isi-set ang random walk length ng message nito hanggang 4. Tinitiyak nito na ang lahat ng mga peer sa network ay laging may sariwang impormasyon tungkol sa iba pang mga peer na maaari nilang iimbak sa kanilang passive view para sa mga layunin ng pag-aayos ng network, sa tuwing alinman sa kanilang mga aktibong peers ay hindi tumutugon o dumi-disconnect.
Efficient Gossiping
Ang mga aktibong peers lamang ang lumalahok sa pagpapakalat ng mensahe sa pagitan ng mga peers. Ang mga aktibong peer ay bumubuo ng isang overlay na network sa pampublikong internet at mayroong mga cycle sa connectivity graph sa pagitan ng mga node. Upang paganahin ang mahusay na gossiping ng mga mensahe sa pagitan ng mga peers sa network, kailangan muna nating i-minimize ang duplicate message propagation sa pagitan ng mga peers at pangalawa, hanapin ang pinakamainam na ruta para sa mga mensahe.
Nagagawa ito sa pamamagitan ng paggamit ng Epidemic Broadcast Trees⁸ algorithm na bumubuo ng pinakamababang spanning tree sa pagitan ng mga peer, sa pamamagitan ng paghahati ng mga peer sa isang grupo ng mga eager-push node at lazy push node. Ang mga eager-push node ay palaging nagpapasa ng mga mensahe sa sandaling matanggap sila ng anumang node.
Ang mga lazy push node ay nakakakuha ng isang batch ng mga message ID na nakikita ng kasalukuyang node kada 500ms. Sa tuwing mapapansin ng isang node na mayroong message id sa lazy-push batch na hindi natanggap mula sa upstream parent node nito, muling bubuuin nito (GRAFT) ang koneksyon at ibabalik ang active-push status nito. Binubuo nito ang minimum spanning tree repair mechanism kung sakaling bumaba ang isa sa mga node at mabuo ang magkahiwalay na mga graph. Ang mga mensahe ng GRAFT ay nagpapanumbalik ng buong koneksyon sa network.
Sa tuwing ang isang natanggap na mensahe ay makikita na isang duplicate ng isang dating natanggap na mensahe mula sa isang aktibong node, kung gayon ang koneksyon sa node na iyon ay itinuturing na isang cycle sa graph at nagiging Lazy-Push sa pamamagitan ng pagpapadala ng isang PRUNE na mensahe.
Ang isa pang kaso para sa pagpuputol ng aktibong koneksyon at pagpapalit nito ng isa mula sa lazy list ay kapag napagmasdan namin na ang bilang ng mga hop na dinaanan ng isang mensahe upang makaabot sa pamamagitan ng lazy node ay mas mababa ng 4 hops kaysa sa isang mensahe mula sa masigasig at aktibong peers. Iyon ang bumubuo sa broadcast tree optimization algorithm.
Content Dissemination
Ang mga mensaheng nanalaytay sa pamamagitan ng p2p protocol na inilarawan sa mga nakaraang seksyon ay mga IPFS Bitswap⁹ na mensahe na may mga CID ng content na ginawa ng mga user ng Solcial. Upang mas maunawaan kung paano ginagamit ang Bitswap at IPFS sa Solcial, ilarawan muna natin ang istruktura ng isang profile ng user.
Ang bawat user account sa network ay may tinatawag na profile index. Ang index na ito ang nagtuturo sa mga CID ng mga pinakabagong bersyon ng kanilang content. Ang index ay isang Eventually Consistent Sequence CRDT na bumubuo ng isang hindi nagbabagong log ng mga operasyong isinagawa ng account.
Ang index ng profile ay maaaring ituring bilang isang naka-link na listahan kung saan ang bawat elemento ay tumuturo sa CID ng nakaraang elemento at tinatanggap ng mga peer bilang susunod na element in sequence kung ito ay nilagdaan ng private key ng may-ari ng account. Ang isang mataas na antas na lohikal na halimbawa ng isang profile feed na na-post na naka-encode sa format na ito ay ganito ang hitsura:
{
“author”: “12D3KooWSoeYKbpkb5UoL2T5eiomWRHdxR9cPC4tk11gKU89fFwT”,
“prev”: “QmYtUc4iTCbbfVSDNKvtQqrfyezPPnFvE33wFmutw9PBBk”,
“action”: “append-feed-post”,
“timestamp”: “2022–01–11T15:58Z”,
“params”: {
“content”: “QmV8cfu6n4NT5xRr2AHdKxFMTZEJrA44qgrBCr739BN9Wb”
“enckey”: “z2DhMLJmV8kNQm6zeWUrXQKtmzoh6YkKHSRxVSibscDQ7nq”
},
“signature”: “2Lpnvt23H6qHswCNPmwCCUSas7YNP[…]jV1dC9qdNPR4zDqsCuBX”
}
Ang isang entry na tulad nito ay may sariling CID at nai-broadcast bilang IPFS PB-DAG¹⁰ tumututol sa /solcial/content HyparView overlay na paksa. Ang entry na ito ay naka-link sa dati nitong entry at anumang karagdagang content sa pamamagitan ng recursively querying linked CIDs user ay maaaring makuha ang buong account history at content.
Ang bagay na ito ay unang nava-validate ng sinumang tumatanggap na peer kung ang lagda ng content ay tumutugma sa public key ng may-akda. Sa kaso ng isang failed signature verification, ang sender peer ay permanenteng pinagbawalan mula sa kasalukuyang node dahil sa paglabag sa protocol. Ang isang successful signature validation ay nagpapalaganap ng content sa lahat ng iba pang mga peers na interesado sa content na isinulat ng account na ito.
Kapag ang naturang CID ay natanggap ng isang peer, ito ay idinaragdag sa log ng mga operasyon ng author. Ang kabuuan ng lahat ng mga operasyong isinagawa ng author ay bumubuo sa kasalukuyang estado ng profile.
Bilang default, ang bawat node ay nagpi-pin at nagseed ng sarili nitong account content at content ng mga kaibigan nito. May mga espesyal na peer na itinatayo namin bilang bahagi ng aming imprastraktura na tinatawag naming mga beacon node at sila ay tulad ng mga regular na peer ng user, maliban kung interesado sila sa content ng lahat at nagsisilbing uri ng serbisyong pinning ng IPFS na partikular sa Social para sa lahat ng content kung sakaling offline ang lahat ng kasalukuyang seeder. Isipin ang mga ito bilang mga node na kaibigan ng lahat. Maaaring gumana ang network nang wala ang mga ito, ngunit nagbibigay sila ng karagdagang layer ng availability ng content.
Read Access
Ang lahat ng nasa Solcial p2p overlay ay maaaring mag-query, mag-download at magbigay ng anumang nilalaman ng user sa pamamagitan ng pag-broadcast ng IWANT at IHAVE Bitswap na mga mensahe sa paksang /solcial/content na may CID ng pinakamataas na antas ng root index ng account, at pagkatapos ay paulit-ulit na humiling ng lahat ng naka-link na CID.
Ang paunang pag-sync ng isang account, o pagkuha ng mga pinakabagong entry ng account ay nakakamit sa pamamagitan ng pag-broadcast ng HEAD na mensahe sa /solcial/sync na paksa, kung saan ang iba pang mga peer na mga seeder (kabilang ang mga beacon node) ay tumutugon sa CID ng pinakabagong nilalaman na alam nila ng. Ang pagsasalin sa pagitan ng mga handle ng user at mga public key ng user ay ginagawa sa pamamagitan ng pagku-query sa Solana blockchain.
Ang nakaraang entry field ay maaaring gamitin upang lutasin ang magkasalungat na HEAD at magpasya sa pinakabagong entry.
Write Access
Upang makapagsulat sa isang account log, ang user ay dapat magkaroon ng private key ng ED25519 keypair na tumutugma sa kanilang account ID. Sa pagkakaroon ng key na iyon, makakabuo ang user ng wastong lagda ng isang entry na idinaragdag nila sa log na hindi tatanggihan ng ibang mga peer sa network.
Privileged Content Access
Ang ilang content na-post ng mga user ay inilaan lamang para sa isang piling pangkat ng mga recipients, gaya ng mga feed ng subscription sa Tier-1 o Tier-2. Ang mga post na iyon ay unang naka-encrypt gamit ang isang symmetric AES-256 encryption key. Ang hash ng key na iyon ay naka-attach sa metadata ng nilalaman sa orihinal na post.
Ang susi ay ipinamamahagi sa isang random na subset ng mga kwalipikadong peer sa NOISE encrypted channel na itinatag sa panahon ng libp2p handshake. Maaaring piliing payagan ng may-akda ng post na payagan ang mga beacon node na lumahok din sa key exchange scheme na ito upang gawing near-instant prosecess para sa lahat ng user, ngunit hindi nila kailangan kung naniniwala sila na ang kanilang content ay sobrang sensitibo. Kapag gustong i-decipher ng isang kwalipikadong user ang content, nagpapadala sila ng GETKEY message sa /solcial/keyexchange overlay na paksa na may hash ng encryption key.
Ang lahat ng mga peer na may hawak ng key na iyon na online ay susuriin ang pagiging karapat-dapat ng peer para makuha ang key na iyon sa pamamagitan ng pag-query sa blockchain at pag-verify kung hawak ng user ang mga kinakailangang token para sa pag-access sa content. Pagkatapos ng matagumpay na pag-verify, ang susi ay ipinapa dala sa requesting peer gamit ang direktang koneksyon ng quic/noise na nagba-bypass sa gossip protocol.
Platform support
Ang peer to peer protocol na ito para sa censorship resistant content ay available lang para sa mga desktop at mobile clients at hindi pa available sa web interface. Ito ay dahil sa mga limitasyon ng browser. Ang mga browser ay likas na idinisenyo bilang mga consumers of content hosted on server at ipinagbabawal ng kanilang modelo ng seguridad ang pagtanggap ng mga random na koneksyon mula sa ibang mga makina.
Ang web version ay halos palaging centralized dahil sa paraan ng paggana ng mga browser at ang buhay ng isang tab ng browser ay maikli, at anumang content na ginawa sa pamamagitan ng web interface ay sasalamin sa p2p ng mga beacon node. Ang anumang content na nagamit ng web client ay magiging kopya ng p2p. Ang P2P ang pinagmumulan ng katotohanan.
Ang pinagbabatayan na teknikal na stack ay ipinatupad gamit ang Rust, libp2p na may mga binding sa React Native at Tauri¹¹.
[1] Leitao, Joao, José Pereira, and Luis Rodrigues. “HyParView: A membership protocol for reliable gossip-based broadcast.”
[2] https://en.wikipedia.org/wiki/QUIC
[3] https://libp2p.io/
[4] https://www.google.com/intl/en/ipv6/statistics.html
[5] https://docs.libp2p.io/concepts/circuit-relay/
[6] https://datatracker.ietf.org/doc/html/rfc5766
[7] https://docs.libp2p.io/reference/glossary/#multihash
[8] Leitao, Joao, Jose Pereira, and Luis Rodrigues. “Epidemic broadcast trees.” 2007 26th IEEE International Symposium on Reliable Distributed Systems (SRDS 2007). IEEE, 2007.
[9] https://docs.ipfs.io/concepts/bitswap/
[10] https://github.com/ipld/ipld/blob/master/specs/codecs/dag-pb/spec.md
[11] https://tauri.studio/
Ano ang Solcial?
Ang Solcial ay isang decentralized social network na naglalayong bigyan ang mga user ng kapangyarihan ng web3 sa pamamagitan ng pagpayag sa mga user na makipag-ugnayan sa isa't isa nang hindi natatakot sa censorship, at pagpayag sa mga content creators na magantimpalaan ng patas sa halaga ng merkado.
Makipag-ugnayan
Telegram: https://t.me/solcial
Twitter: https://twitter.com/solcialofficial
Discord: https://discord.com/invite/solcial
Blog: https://blog.solcial.io/
Web: https://solcial.io
Email: [email protected]
Linktree: https://linktr.ee/solcial
