Oo, Maaaring Kailangan Mo ng Blockchain

Si Balaji S. Srinivasan ay ang dating CTO ng Coinbase, isang Board Partner sa Andreessen Horowitz at isang miyembro ng advisory board ng CoinDesk.

Ang sumusunod na artikulo ay orihinal na lumabas sa Consensus Magazine, eksklusibong ipinamahagi sa mga dadalo ng Consensus 2019 event ng CoinDesk.

Mayroong isang tiyak na uri ng developer na nagsasaad na ang mga blockchain ay makatarungan kakila-kilabot mga database. Habang nagpapatuloy ang salaysay, bakit hindi na lang gamitin ang PostgreSQL para sa iyong aplikasyon? Ito ay mature, matatag, at mataas ang pagganap. Kung ikukumpara sa mga relational database, sinasabi ng mga may pag-aalinlangan na ang mga blockchain ay mabagal, clunky at mahal na mga database na T sukat.

Habang ang ilang mga kritika ng kritikang ito ay nasa labas na (1, 2), Iminumungkahi ko ang ONE simpleng rebuttal ng pangungusap: ang mga pampublikong blockchain ay kapaki-pakinabang para sa pag-imbak ng nakabahaging estado, lalo na kapag ang nakabahaging estado na iyon ay kumakatawan sa mahalagang data na gustong i-export/i-import ng mga user nang walang error — tulad ng kanilang pera.

Ang problema sa pag-export/pag-import ng data

Tingnan ang mga cloud diagram para sa Amazon Web Services, Microsoft Azure, o Google Cloud. May mga icon para sa mga load balancer, transcoder, queues, at mga function ng lambda.

May mga icon para sa mga VPC at bawat uri ng database sa ilalim ng SAT, kabilang ang new-ish pinamamahalaang blockchain mga serbisyo (na naiiba sa mga pampublikong blockchain, kahit na potensyal na kapaki-pakinabang sa ilang mga pangyayari).

Ang T ICON ay nakabahaging estado sa pagitan ng mga account. Ibig sabihin, ang mga cloud diagram na ito ay tahasang ipinapalagay na ang isang entity at ang mga empleyado nito (ibig sabihin, ang entity na may access sa cloud root account) ay ang nag- ONE naglalatag ng diagram ng arkitektura at nagbabasa mula o sumusulat sa application na pinagbabatayan nito. Mas tiyak, karaniwang ipinapalagay ng mga diagram na ito ang pagkakaroon ng iisang aktor sa ekonomiya, katulad ng entity na nagbabayad ng mga cloud bill.*

Ngunit kung isasalarawan natin ang mga cloud diagram para sa hindi lamang ONE kundi ONE daang corporate economic actor sa isang pagkakataon, may ilang mga agarang tanong na bumangon. Maaari bang mag-interoperate ang mga aktor na ito? Maaari bang makuha ng kanilang mga user ang kanilang data at dalhin ito sa iba pang mga application? At dahil ang mga gumagamit ay mismong mga aktor sa ekonomiya, kung ang data na ito ay kumakatawan sa isang bagay na may halaga sa pananalapi, maaari bang magtiwala ang mga gumagamit na ang kanilang data ay T nabago sa lahat ng pag-export at pag-import na ito?

Ito ang mga uri ng tanong na lumalabas kapag iniisip natin ang tungkol sa pag-export at pag-import ng data mula sa aplikasyon ng bawat entity bilang isang first-class na kinakailangan. At (kasama ang mga pagbubukod na papasukin natin), sa pangkalahatan, ang sagot sa mga tanong na ito ngayon ay karaniwang hindi.

Hindi — ang iba't ibang mga application ay karaniwang T interoperable na software, o pinapayagan ang kanilang mga user na madaling i-export/i-import ang kanilang data sa isang karaniwang form, o bigyan ang mga user ng katiyakan na ang kanilang data ay T sinasadyang pinakialaman o hindi sinasadyang nasira sa lahat ng pag-export at pag-import.

Ang dahilan kung bakit nagmumula sa mga insentibo. Para sa karamihan ng mga pangunahing serbisyo sa internet, walang pinansiyal na insentibo upang bigyang-daan ang mga user na i-export ang kanilang data, lalo pa upang bigyang-daan ang mga kakumpitensya na mabilis na mag-import ng nasabing data. Habang tinatawag ito ng ilan na maaaring dalhin ng data problema, tawagin natin itong problema sa pag-export/pag-import ng data upang ituon ang pansin sa mga partikular na mekanismo para sa pag-export at pag-import.

Mga kasalukuyang diskarte sa problema sa pag-export/pag-import ng data

Kahit na ang mga insentibo sa pananalapi ay T pa naroroon para sa isang pangkalahatang solusyon sa problema sa pag-export/pag-import ng data, ang mga mekanismo ay ginawa para sa maraming mahahalagang espesyal na kaso. Kasama sa mga mekanismong ito ang mga API, JSON/PDF/CSV export, MBOX file, at (sa konteksto ng pagbabangko) SFTP.

Pag-usapan natin ang mga ito upang maunawaan ang kasalukuyang estado ng mga gawain.

• Mga API. Ang ONE sa mga pinakasikat na paraan upang mag-export/mag-import ng data ay sa pamamagitan ng Application Programming Interfaces, na mas kilala bilang mga API. Hinahayaan ka ng ilang negosyo na mailabas ang ilan sa iyong data, o binibigyan ka ng kakayahang magsulat ng data sa iyong account. Pero may bayad. Una, ang kanilang panloob na format ng data ay karaniwang pagmamay-ari at hindi isang pamantayan sa industriya. Pangalawa, kung minsan ang mga API ay hindi sentral sa kanilang CORE negosyo at maaaring maging naka-off. Pangatlo, kung minsan ang mga API ay sentro sa kanilang CORE negosyo at ang presyo ay maaaring kapansin-pansing itinaas. Sa pangkalahatan, kung nagbabasa o nagsusulat ka sa isang naka-host na API, nasa awa ka ng API provider. Tinatawag namin itong platform risk, at ang pagiging unceremoniously de-platformed ay mayroon sinaktan marami a pagsisimula.
• JSON. Ang isa pang nauugnay na solusyon ay ang payagan ang mga user o script na mag-download ng mga JSON file, o basahin/isulat ang mga ito sa mga nabanggit na API. Ayos lang ito, ngunit ang JSON ay napaka-free form at maaaring ilarawan ang halos kahit ano. Halimbawa, ang Facebook Graph API at ng LinkedIn REST API makitungo sa mga katulad na bagay ngunit nagbabalik ng ibang mga resulta ng JSON.
• PDF. Ang isa pang bahagyang solusyon ay ang payagan ang mga user na mag-export ng PDF. Gumagana ito para sa mga dokumento, dahil ang PDF ay isang bukas na pamantayan na maaaring basahin ng iba pang mga application tulad ng Preview, Adobe Acrobat, Google Drive, Dropbox, at iba pa. Ngunit ang isang PDF ay sinadya upang maging isang pangwakas na produkto, na basahin ng isang Human. Hindi ito sinadya upang maging isang input sa anumang application bukod sa isang PDF viewer.
• CSV. Ang hamak na comma separated value file ay nagiging mas malapit sa kung ano ang gusto namin para sa isang pangkalahatang solusyon sa problema sa pag-import/pag-export ng data. Hindi tulad ng backend ng isang proprietary API, ang CSV ay isang karaniwang format inilarawan ni RFC 4180. Hindi tulad ng JSON, na maaaring kumatawan sa halos anumang bagay, ang isang CSV ay karaniwang kumakatawan lamang sa isang talahanayan. At hindi tulad ng isang PDF, ang isang CSV ay karaniwang maaaring i-edit nang lokal ng isang user sa pamamagitan ng isang spreadsheet o ginagamit bilang nababasa ng machine na input sa isang lokal o cloud application. Dahil ang karamihan sa mga uri ng data ay maaaring katawanin sa isang relational database, at dahil ang mga relational database ay kadalasan na-export bilang isang hanay ng mga posibleng naglalakihang CSV, medyo pangkalahatan din ito. Gayunpaman, ang mga CSV ay disadvantaged sa ilang paraan. Una, hindi tulad ng isang proprietary API, T sila naka-host. Ibig sabihin, walang iisang canonical na lugar para magbasa o magsulat ng CSV na kumakatawan (sabihin) ang isang talaan ng mga transaksyon o isang talahanayan ng metadata ng mapa. Pangalawa, ang mga CSV ay T tamper resistant. Kung ang isang user ay nag-export ng isang talaan ng mga transaksyon mula sa serbisyo A, binago ito, at muling i-upload ito sa serbisyo B, ang pangalawang serbisyo ay hindi mas matalino. Pangatlo, ang mga CSV ay T mga built-in na pagsusuri sa integridad upang maprotektahan laban sa hindi sinasadyang error. Halimbawa, ang mga column ng isang CSV ay T tahasang uri ng impormasyon, na nangangahulugan na ang isang column na naglalaman ng mga buwan ng taon mula 1-12 ay maaaring awtomatikong ma-convert ang uri nito sa pag-import sa isang simpleng integer, na magdulot ng pagkalito.
• MBOX. Habang hindi gaanong kilala kaysa sa CSV, ang format ng MBOX para sa kumakatawan sa mga koleksyon ng mga mensaheng email ay ang pinakamalapit na bagay doon sa isang standardized na istraktura ng data na binuo para sa pag-import at pag-export sa pagitan ng mga pangunahing platform at independiyenteng mga application. Sa katunayan, mayroon mga papel nagmumungkahi ng paggamit ng MBOX sa mga konteksto sa labas ng email. Habang ang CSV ay kumakatawan sa tabular na data, ang MBOX ay kumakatawan sa isang uri ng log-structured data. Ito ay mahalagang isang solong malaking plain text file ng mga mensaheng email sa magkakasunod na pagkakasunud-sunod, ngunit maaari ring kumatawan mga larawan/mga attachment ng file sa pamamagitan ng MIME. Tulad ng CSV, ang mga MBOX file ay isang bukas na pamantayanat maaaring i-export, i-edit nang lokal, at muling i-import. At tulad ng CSV, ang MBOX ay may mga disadvantages ng walang canonical host o intrinsic data integrity check.
• SFTP. Bago tayo magpatuloy, may ONE pang mekanismo ng pag-export/pag-import ng data na nararapat banggitin: ang secure na file transfer protocol, o SFTP. Bagama't kagalang-galang, ito talaga ang paraan ng pagpapadala ng mga indibidwal ng mga bayad sa ACH pabalik- FORTH sa isa't isa. Sa pangkalahatan, ang mga institusyong pampinansyal ay gumagamit ng mga SFTP server upang kumuha ng data ng elektronikong transaksyon espesyal na format na mga file at ipadala ito sa Federal Reserve bawat araw upang i-sync ang mga ACH debit at credit sa isa't isa (tingnan dito, dito, dito, at dito).

Ang bawat isa sa mga mekanismong ito ay malawakang ginagamit. Ngunit hindi sapat ang mga ito para i-enable ang pangkalahatang kaso ng pag-import at pag-export na lumalaban sa tamper ng mahalagang data sa pagitan ng mga arbitrary na pang-ekonomiyang aktor — kung sila man ay mga corporate entity, indibidwal na user, o walang ulo na script. Para diyan, kailangan namin ng mga pampublikong blockchain.

Ang mga pampublikong blockchain ay nagbibigay-daan sa ibinahaging estado sa pamamagitan ng pagbibigay-insentibo sa interoperability. Ang mga pampublikong blockchain ay nagko-convert ng maraming uri ng mga problema sa pag-import/pag-export ng data sa isang pangkalahatang klase ng mga pinagsasaluhang problema ng estado. At ginagawa nila ito sa bahagi sa pamamagitan ng pagsasama ng marami sa mga pinakamahusay na tampok ng mga mekanismong inilarawan sa itaas.

• Ang mga pampublikong blockchain ay nagbibigay ng mga canonical na pamamaraan para sa read/write access tulad ng isang naka-host na corporate API, ngunit walang parehong panganib sa platform. Walang sinumang aktor sa ekonomiya ang maaaring magsara o tanggihan ang serbisyo sa mga kliyente ng isang desentralisadong pampublikong blockchain tulad ng Bitcoin o Ethereum.
• Binibigyang-daan din nila ang mga indibidwal na user na mag-export ng kritikal na data sa kanilang lokal na computer o sa isang bagong application tulad ng JSON/CSV/ MBOX (sa pamamagitan ng pagpapadala ng mga pondo o pag-export ng mga pribadong key) habang nagbibigay ng mga cryptographic na garantiya ng integridad ng data.
• Nagbibigay ang mga ito ng paraan para sa mga di-makatwirang pang-ekonomiyang aktor (mga korporasyon man, indibidwal na gumagamit, o mga programa) upang walang putol na interoperate. Ang bawat ekonomikong aktor na nagbabasa mula sa isang pampublikong blockchain ay nakikita ang parehong resulta, at sinumang pang-ekonomiyang aktor na may sapat na pondo ay maaaring sumulat sa isang pampublikong blockchain sa parehong paraan. Walang setup ng account ang kailangan at walang aktor ang maaaring ma-block mula sa read/write access.
• At marahil ang pinakamahalaga, ang mga pampublikong blockchain ay nagbibigay ng mga insentibo sa pananalapi para sa interoperability at integridad ng data.

Ang huling puntong ito ay nararapat na paliwanagan. Ang isang pampublikong blockchain tulad ng Bitcoin o Ethereum ay karaniwang nagtatala ng paglilipat ng mga bagay na may halaga ng pera. Ang bagay na ito ay maaaring ang intrinsic Cryptocurrency ng chain, isang token na ibinigay sa ibabaw ng chain, o isa pang uri ng digital asset.

Dahil ang data na nauugnay sa isang pampublikong blockchain ay kumakatawan sa isang bagay na may halaga ng pera, sa wakas ay naghahatid ito ng pinansiyal na insentibo para sa interoperability. Pagkatapos ng lahat, ang anumang web o mobile app na gustong tumanggap (sabihin) BTC ay dapat igalang ang mga kombensiyon ng Bitcoin blockchain. Sa katunayan, ang mga developer ng application ay walang pagpipilian dahil sa katotohanan na ang Bitcoin sa pamamagitan ng disenyo ay may isang solong, kanonikal na pinakamahabang proof-of-work chain na may cryptographic validation ng bawat bloke sa chain na iyon.

So, iyon ang financial incentive para sa pag-import.

Tulad ng para sa insentibo para sa pag-export, pagdating sa pera sa partikular, hinihiling ng mga gumagamit ang kakayahang mag-export nang may kumpletong katapatan, at napakabilis. Ito ay hindi ang kanilang mga lumang pusa pics, na maaaring sila ay ok sa pagkawala ng track ng dahil sa abala o teknikal na mga isyu. Ito ay kanilang pera, kanilang Bitcoin, kanilang Cryptocurrency. Anumang application na nagtataglay nito ay dapat gawin itong available para sa pag-export kapag gusto nila itong bawiin, nangangahulugan man iyon ng pagsuporta sa pagpapagana ng pagpapadala, pag-aalok ng mga pribadong key backup, o pareho. Kung hindi, ang aplikasyon ay malamang na hindi makatanggap ng mga deposito sa unang lugar.

Kaya, iyon ang pinansiyal na insentibo para sa pag-export. Kaya, ang isang pampublikong blockchain ay nagbibigay ng matipid na insentibo sa bawat economic actor na nakikipag-ugnayan dito na gumamit ng parehong import/export na format gaya ng bawat ibang aktor, maging sila man ay korporasyon, user, o program. Sa ibang paraan, ang mga pampublikong blockchain ay ang susunod na hakbang pagkatapos ng open source, dahil nagbibigay sila ng bukas na data. Sinuman ay maaaring mag-code ng kanilang sariling block explorer sa pamamagitan ng pagbabasa mula sa isang pampublikong blockchain, at sinuman ay maaaring lumikha ng kanilang sariling wallet na may kakayahang sumulat sa isang pampublikong blockchain.

Iyan ay isang tunay na pambihirang tagumpay. Mayroon na kaming maaasahang paraan para ma-insentibo ang paggamit ng ibinahaging estado, upang sabay-sabay na payagan ang milyun-milyong indibidwal at kumpanya na makabasa mula sa (at libu-libo na sumulat sa) parehong data store habang ipinapatupad ang isang karaniwang pamantayan at pinapanatili ang mataas na kumpiyansa sa integridad ng data.

Ibang-iba ito sa status quo. Karaniwang T mo ibinabahagi ang root password sa iyong database sa internet, dahil karaniwang nasisira ang isang database na nagbibigay-daan sa sinuman na magbasa/magsulat dito. Ang mga pampublikong blockchain ay nilulutas ang problemang ito gamit ang cryptography sa halip na mga pahintulot, na lubhang nagpapataas ng bilang ng mga sabay-sabay na gumagamit.

Totoo na ngayon ang mga pampublikong blockchain ay karaniwang nakatutok sa monetary at financial application, kung saan ang pinagbabatayan na dataset ay kumakatawan sa isang append-only na kasaysayan ng transaksyon na may mga hindi nababagong tala. Nililimitahan nito ang kanilang pangkalahatan, sa mga tuntunin ng pagtugon sa lahat ng iba't ibang bersyon ng problema sa pag-import/pag-export ng data. Ngunit mayroong patuloy na pag-unlad sa mga pampublikong blockchain na bersyon ng mga bagay tulad ng OpenStreetMaps, Wikipedia, at Twitter pati na rin ang mga system tulad ng Filecoin/IPFS. Ang mga ito ay T lamang kumakatawan sa mga talaan ng mga transaksyon sa pananalapi kung saan ang immutability ay isang kinakailangan, ngunit maaaring kumatawan sa iba pang mga uri ng data (tulad ng mapa o mga entry sa encyclopedia) na regular na ina-update.

Tama, ang mga mas bagong uri ng pampublikong blockchain-based na system na ito ay maaaring magbigay-daan sa sinumang economic actor na may sapat na pondo at/o cryptographic na mga kredensyal na hindi lamang magbasa at magsulat kundi mag-edit din ng sarili nilang mga tala habang pinapanatili ang integridad ng data. Dahil sa kakayahang ito, walang dahilan na T ONE maglagay ng SQL layer sa ibabaw ng isang pampublikong blockchain upang gumana sa nakabahaging estado na ibinibigay nito, tulad ng isang makalumang relational database. Nagreresulta ito sa isang bagong uri ng database na walang pribilehiyong may-ari, kung saan lahat ng pitong bilyong tao sa planeta (at ang kanilang mga script!) ay mga awtorisadong user, at maaaring sulatan ng anumang entity na may sapat na pondo.

T pa ang araw na iyon. Ito ay nananatili upang makita kung hanggang saan natin maitutulak ang mga kaso ng paggamit para sa mga pampublikong kadena. At marami ang mga hamon sa pag-scale. Ngunit sana, malinaw na habang ang mga pampublikong blockchain ay talagang isang bagong uri ng database, nag-aalok sila ng isang bagay na medyo naiiba kaysa sa kung ano ang inaalok ng isang tradisyonal na database.

* Ang ONE pagbubukod ay ang tinatawag na tampok na "Requester Pays" na inaalok ng Amazon at iba pang mga serbisyo sa cloud. Ito ay isang cool na tampok na nagbibigay-daan sa isang tao na magbayad upang sumulat sa iyong S3 bucket. Ngunit ito ay pinahintulutan – kinakailangan pa rin nito ang bawat magiging manunulat na magbukas ng isang AWS account, at ang may-ari ng bucket ay kailangang maging handa na hayaan silang lahat na magsulat sa kanilang bucket, kaya mayroon pa ring isang natatanging may-ari.

Larawan ng database sa pamamagitan ng Shutterstock