Баладжи Сринивасан е бивш технически директор на КойнБейз, съдружник в управителния съвет на Andreessen Horowitz и член на консултативния съвет на CoinDesk.
Следващата статия първоначално се появи в Consensus Magazine, разпространявана изключително за участниците в CoinDesk на събитието Consensus 2019.
Съществува определен тип програмисти, които заявяват, че Блокчейн технологиите са просто ужасни бази данни. В този ред на мисли, защо просто не използвате PostgreSQL за вашето приложение? Той е зрял, стабилен и с висока производителност. В сравнение с релационните бази данни, скептикът твърди, че блокчеините са само бавни, тромави и скъпи бази данни, които не са мащабирани.
Четете още: Всички новини за Блокчейн технологиите
Докато някои критики на тази критика вече са налице (1, 2), бих предложил едно опровержение с едно изречение: обществените блокчеини са полезни за съхраняване на споделено състояние, особено когато това споделено състояние представлява ценни данни, които потребителите искат да експортират/импортират без грешка – като техните пари.
Проблемът за експортиране/импортиране на данни
Разгледайте диаграмите в облака за уеб услугите на Amazon, Microsoft Azure или Google Cloud. Има икони за балансиращи натоварвания, транскодери, опашки и ламбда функции.
Има икони за VPCs и всеки тип база данни под слънцето, включително услугите на new-ish, управлявани от Блокчейн (които се различават от обществените Блокчеини, макар и потенциално полезни при някои обстоятелства).
Не съществува икона за споделено състояние между профилите. Това означава, че тези облачни диаграми имплицитно приемат, че една единица и нейните служители (а именно, лицето с достъп до акаунта в облака) е единственото, което излага диаграмата на архитектурата и чете от или пише на приложението, което е в основата. По-точно тези диаграми обикновено предполагат наличието на един-единствен икономически участник, а именно предприятието, което плаща сметките за облацчни услуги.
Но ако визуализираме облачните диаграми за не само един, но сто корпоративни икономически участници едновременно, възникват някои непосредствени въпроси. Могат ли тези участници да си взаимодействат? Могат ли потребителите им да извадят данните си и да ги въведат в други приложения? И като се има предвид, че самите потребители са икономически участници, ако тези данни представляват парична стойност, могат ли потребителите да са сигурни, че техните данни не са били променени по време на целия този износ и внос?
Четете още: Изграждане на хибридни блокчейн/облачни приложения с Етериум, Гугъл Cloud и Chainlink
Това са типовете въпроси, които възникват, когато мислим за износа и вноса на данни от заявлението на всяко предприятие като първокласно изискване. И (с изключенията, в които ще влезем), като цяло отговорът на тези въпроси днес обикновено е не.
Не – различни приложения обикновено нямат оперативно съвместим софтуер и не позволяват на потребителите лесно да експортират/импортират данните си в стандартен формуляр или да дават на потребителите увереност, че данните им не са били умишлено подправени или непреднамерено повредени по време на износа и импортирането.
Причината, поради която се свежда до стимули. За повечето основни интернет услуги просто няма финансов стимул, който да позволи на потребителите да изнасят своите данни, да не говорим да позволи на конкурентите бързо да импортират споменатите данни. Докато някои наричат това проблемът с преносимостта на данните, нека го наречем проблем за износ/внос на данни, за да се съсредоточи вниманието върху специфичните механизми за износ и внос.
Текущи подходи към проблема за износ/внос на данни
Въпреки че финансовите стимули все още не са налице за общо решение на проблема с износа/вноса на данни, бяха създадени механизми за много важни специални случаи. Тези механизми включват API/JSON/PDF/CSV износ, MBOX файлове и (в банков контекст) SFTP.
Нека преминем през тях, за да разберем сегашното състояние на нещата.
- APIs. Един от най-популярните начини за експортиране/импортиране на данни е чрез приложни програмни интерфейси, по-известни като API. Някои фирми ви позволяват да извлечете част от данните си или да ви даде възможност да записвате данни в профила си. Но има цена. Първо, техният вътрешен формат на данни е типично патентован, а не индустриален стандарт. Второ, понякога приложните програмни интерфейси не са централни за основния си бизнес и могат да бъдат изключени. Трето, понякога приложните програмни интерфейси (API) са централни за основния си бизнес и цената може да бъде драстично повишена. Като цяло, ако четете или пишете на хостван API, вие сте на милостта на доставчика на API. Ние наричаме този риск на платформата, а да бъдеш безцеремонно де-платформиран, е навредил на стартирането.
- JSON. Друго свързано решение е да позволи на потребителите или скриптовете да изтеглят JSON файлове или да ги четат / записват в гореспоменатите API. Това е добре, доколкото става дума, но JSON е много свободна форма и може да опише почти всичко. Например, API на Facebook и API за REST на LinkedIn се справят с подобни неща, но връщат много различни резултати на JSON.
- PDF формат. Друго много частично решение е да се позволи на потребителите да експортират PDF. Това работи за документи, тъй като PDF е отворен стандарт, който може да се прочете от други приложения като Preview, Adobe Acrobat, Google Drive, Dropbox и т.н. Но един PDF документ е предназначен да бъде краен продукт, който да се чете от човек. Той не е предназначен да бъде вход за всяко приложение освен PDF преглед.
- CSV. Скромен файл със стойности, разделен със запетая, се доближава до това, което искаме за общо решение на проблема с импорта / експорта на данни. За разлика от бекенда на частен API, CSV е стандартен формат, описан от RFC 4180. За разлика от JSON, който може да представлява почти всичко, CSV обикновено представлява само таблица. За разлика от PDF, CSV обикновено може да се редактира локално от потребител чрез електронна таблица или да се използва като машинно-четим вход за локално или облачно приложение. Тъй като повечето видове данни могат да бъдат представени в релационна база данни, и тъй като релационните бази данни обикновено могат да бъдат експортирани като набор от евентуално гигантски CSV, това също е доста общо. Въпреки това, CSV файловете са в неравностойно положение по няколко начина. Първо, за разлика от собствения API, те не са хоствани. Това означава, че няма единно канонично място за четене или писане на CSV, представящо (да речем) запис на транзакции или таблица с метаданни на картата. Второ, CSV файловете не са защитени от намеса. Ако потребител изнесе запис от транзакции от услуга А, модифицира го и го презареди в сервиз Б, втората услуга няма да е по-разумна. Трето, CSV файловете нямат вградени проверки за цялостност, за да се предпазят от непреднамерени грешки. Например колоните на CSV не съдържат изрична информация за типа, което означава, че колона, съдържаща месеците от годината от 1-12, може да има свой тип автоматично преобразуване при импортиране в обикновено число, което води до объркване.
- MBOX. Макар и по-малко известен от CSV, MBOX форматът за представяне на колекции от имейл съобщения е най-близкото до стандартизираната структура на данни, изградена за импортиране и експортиране между големи платформи и независими приложения. Всъщност има документи, предлагащи използването на MBOX в контекст извън електронната поща. Докато CSV представлява таблични данни, MBOX представлява тип данни, структурирани с лог. По същество това е един огромен обикновен текстов файл с имейл съобщения в хронологичен ред, но може също да представлява изображения / прикачени файлове чрез MIME. Подобно на CSV, MBOX файловете са отворен стандарт и могат да бъдат експортирани, редактирани локално и реимпортирани. И подобно на CSV, MBOX има недостатъците на каноничен хост или вътрешна проверка на целостта на данните.
- SFTP. Преди да продължим напред, има още един механизъм за експортиране / импортиране на данни, който заслужава да бъде споменат: протоколът за защитено прехвърляне на файлове или SFTP. Макар и почитаеми, това всъщност е начинът, по който индивидите изпращат ACH плащания напред и назад един към друг. По същество финансовите институции използват SFTP сървъри, за да вземат данни за електронни транзакции в специално форматирани файлове и да ги предават на Федералния резерв всеки ден, за да синхронизират дебитите и кредитите на ACH (виж тук, тук, тук и тук).
Всеки един от тези механизми е широко използван. Но те са недостатъчни, за да позволят общия случай на внос и износ на ценни данни, които са устойчиви на подправяне, между произволни икономически субекти – независимо дали са юридически лица, индивидуални потребители или скриптове без глава. За това ни трябват обществени блокхейн.
Четете още: Visa се възражда с услуга за бизнес плащания, задвижвана от Блокчейн
Обществените блокове позволяват споделено състояние чрез стимулиране на оперативната съвместимост. Обществените блокове превръщат много видове проблеми с импортиране / експортиране на данни в общ клас на споделени проблеми на държавата. И те правят това частично чрез включването на много от най-добрите характеристики на описаните по-горе механизми.
- Обществените блокове осигуряват канонични методи за достъп за четене / запис като хостван корпоративен API, но без същия риск за платформата. Никой икономически участник не може да изключи или да отрече услугата на клиентите на децентрализирана обществена блок-верига като биткойн или етер.
- Те също така позволяват на отделни потребители да експортират критични данни към техния локален компютър или към ново приложение, като JSON / CSV / MBOX (или чрез изпращане на средства или експортиране на частни ключове), като същевременно осигуряват криптографски гаранции за целостта на данните.
- Те осигуряват възможност за произволни икономически участници (независимо дали корпорации, отделни потребители или програми) за безпроблемно взаимодействие. Всеки стопански субект, който чете от обществен блокчейн, вижда същия резултат и всеки икономически актьор с достатъчно средства може да пише по един и същи начин на обществен блокчейн. Не е необходима настройка на акаунта и нито един участник не може да бъде блокиран от достъп за четене и запис.
- И може би най-важното е, че обществените блок-вериги предоставят финансови стимули за оперативна съвместимост и целостта на данните.
Тази последна точка заслужава да бъде изработена. Публична блокчейн, като биткойн или етер, обикновено записва прехвърлянето на неща от парична стойност. Това нещо може да бъде присъщата криптовалута на веригата, токен, издаден на върха на веригата, или друг вид цифров актив.
Тъй като данните, свързани с обществен блокчейн, представляват парична стойност, накрая осигуряват финансовия стимул за оперативна съвместимост. В края на краищата, всяко уеб или мобилно приложение, което иска да получи (да кажем) БТК, трябва да уважава конвенциите на bitcoin blockchain. Разбира се, разработчиците на приложения няма да имат избор поради факта, че Bitcoin по дизайн има една единствена, канонична, най-дълга верига на доказателство на работа с криптографско валидиране на всеки блок в тази верига.
Така че това е финансовият стимул за внос.
Що се отнася до стимулите за износ, когато става дума за пари в частност, потребителите изискват възможността за износ с пълна прецизност и много бързо. Това не е старата им котка, която може да се окаже неподходяща за пропускане поради неудобство или технически проблеми. Това са техните пари, биткойн, криптовалута. Всяко приложение, което го притежава, трябва да го направи достъпно за износ, когато искат да го изтеглят, независимо дали това означава поддържаща функционалност за изпращане, предлагаща архивиране на частен ключ или и двете. Ако не, заявлението едва ли някога ще получи депозити.
Четете още: Ubisoft планира да използва Блокчейн технологията на Етериум
Така че това е финансовият стимул за износ. По този начин, обществен блокчейн икономически стимулира всеки икономически участник, който взаимодейства с него, да използва същия формат за внос / износ, както всеки друг участник, независимо дали е корпорация, потребител или програма. Казано по друг начин, обществените блокове са следващата стъпка след отворен код, тъй като те предоставят открити данни. Всеки може да кодира собствения си изследовател на блокове, като чете от публичен блокчейн, и всеки може да създаде свой собствен портфейл, способен да пише на обществен блокчейн.
Това е истински пробив. Вече имаме надежден начин да стимулираме използването на споделено състояние, за да позволим едновременно на милиони физически лица и компании да четат от (и хиляди да пишат) на едно и също хранилище за данни, като същевременно прилагат общ стандарт и поддържат високо доверие в целостта на данните.
Това е много различно от статуквото. Обикновено не споделяте паролата на root на базата данни в интернет, тъй като базата данни, която позволява на всеки да чете / пише в нея, обикновено се поврежда. Обществените блокове решават този проблем с криптографията, а не с разрешенията, което значително увеличава броя на едновременните потребители.
Вярно е, че днес обществените блокхеини обикновено са фокусирани върху парични и финансови приложения, където основният набор от данни представлява история на транзакции само с добавяне, с неизменни записи. Това ограничава тяхната общност по отношение на адресирането на всички различни версии на проблема за внос / износ на данни. Но продължава да се развива публичните блокови версии на неща като OpenStreetMaps, Wikipedia и Twitter, както и системи като Filecoin / IPFS. Те не представляват само записи на финансови транзакции, където неизменността е изискване, но може да представлява други типове данни (като записи в карти или енциклопедии), които ще бъдат редовно актуализирани.
Четете още: Блокчейн увеличава продажбите на продукти, сподели френския гигант за търговия на дребно Карфур
Правилно, тези по-нови видове обществени системи, базирани на блокчейн, могат да позволят на всеки икономически субект с достатъчно средства и / или криптографски идентификационни данни да не само четат и пишат, но и да редактират своите собствени записи, като запазват целостта на данните. Като се има предвид тази способност, няма причина човек да постави SQL слой върху обществен блокчеин, за да работи със споделеното състояние, което предоставя, точно като старомодна релационна база данни. Това води до нов тип база данни без привилегирован собственик, където всичките седем милиарда души на планетата (и техните скриптове!) Са упълномощени потребители и които могат да бъдат записани от всеки субект с достатъчно средства.
Този ден още не е тук. Остава да се види колко далеч можем да изтласкаме случаите на използване за обществените вериги. И мащабните предизвикателства изобилстват. Но да се надяваме, ясно е, че докато обществените блокове са наистина нов вид база данни, те предлагат нещо съвсем различно от това, което предлага традиционната база данни.