使用GraphQL的區(qū)塊鏈的開源查詢協(xié)議

任何嘗試在(以太坊)區(qū)塊鏈上構(gòu)建分布式應(yīng)用程序(dApps)的人都會同意：雖然區(qū)塊鏈在概念上非常接近數(shù)據(jù)庫，但查詢數(shù)據(jù)庫與查詢區(qū)塊鏈完全相比，感覺就像一個不同的世界。

首先，在區(qū)塊鏈上存儲數(shù)據(jù)存在顯著的性能問題。這些與區(qū)塊鏈的分布式性質(zhì)以及共識協(xié)議和密碼學(xué)的組合所帶來的懲罰有很大關(guān)系。

如果數(shù)據(jù)庫由節(jié)點網(wǎng)絡(luò)組成，其中每個節(jié)點都保留整個數(shù)據(jù)庫的完整副本，并且每個事務(wù)都必須由每個節(jié)點進(jìn)行驗證，那么數(shù)據(jù)庫也會很慢。這就是為什么人們一直在嘗試各種方法來使用區(qū)塊鏈作為數(shù)據(jù)庫，包括改變區(qū)塊鏈結(jié)構(gòu)。

圖表做了不同的事情：它允許區(qū)塊鏈，但提供了一種使用GraphQL有效地索引和查詢存儲在它們上的數(shù)據(jù)的方法。

查詢區(qū)塊鏈

實際上，性能只是從區(qū)塊鏈中檢索數(shù)據(jù)的一部分。情況變得更糟：區(qū)塊鏈沒有任何查詢語言可言。讓它沉入片刻：沒有查詢語言。想象一下沒有查詢語言的數(shù)據(jù)庫!你怎么能得到你需要的東西?人們?nèi)绾螛?gòu)建dApp，真的嗎?經(jīng)過大量的努力和脆弱的特殊代碼。

正如耶穌羅德里格茲在這篇文章中所指出的，區(qū)塊鏈數(shù)據(jù)訪問具有挑戰(zhàn)性，主要是由于三個基本原因：權(quán)力下放，不透明度和順序數(shù)據(jù)存儲。所以人們留下了一些選擇：

編寫自定義代碼以在區(qū)塊鏈上找到所需的數(shù)據(jù)，并在每次需要數(shù)據(jù)時重復(fù)這些(昂貴的)調(diào)用，或者一次檢索數(shù)據(jù)并存儲在脫鏈數(shù)據(jù)庫中，并構(gòu)建索引以指向原始數(shù)據(jù)區(qū)塊鏈數(shù)據(jù)。

這就是圖表的用武之地。圖是一種用于索引和查詢區(qū)塊鏈數(shù)據(jù)的分散協(xié)議。但它不僅僅是一個協(xié)議：Graph還有一個實現(xiàn)，它是開源的并使用GraphQL。

GraphQL是API的一種查詢語言，由Facebook開發(fā)和開源。GraphQL已經(jīng)擁有了自己的生命，它越來越流行并被用于訪問數(shù)據(jù)庫 - 例如，參見Prisma或FaunaDB。

ZDNet與The Graph的聯(lián)合創(chuàng)始人，項目負(fù)責(zé)人Yaniv Tal和研究負(fù)責(zé)人Brandon Ramirez進(jìn)行了問答。

用Tal的話說，現(xiàn)在，在dApp上工作的團(tuán)隊必須編寫大量的自定義代碼并部署專有的索引服務(wù)器，以便有效地為應(yīng)用程序提供服務(wù)。因為所有這些代碼都是自定義的，所以無法驗證索引是否正確完成或?qū)⒋擞嬎阃獍o公共基礎(chǔ)結(jié)構(gòu)。

通過定義執(zhí)行此索引并確定性地提供查詢的標(biāo)準(zhǔn)化方法，Tal繼續(xù)補充說，開發(fā)人員將能夠在可以實施安全性的公共開放式基礎(chǔ)架構(gòu)上運行其索引邏輯。