目前大多數公鏈都將很多密碼學原語的使用場景寫入了共識層,固化的密碼學使用方式對於開發者而言是一個很大的限制。

原文標題:《爲什麼自定義密碼學原語對在區塊鏈上的開發至關重要?》
撰文:Williams

區塊鏈是一個基於密碼學、經濟學和網絡科學的新技術。對於一般的大衆來說,其中的密碼學並不是一門容易親近的學科,甚至是上面提到的三個學科中,大家覺得最有距離感的學科。但身處區塊鏈圈的朋友們一定會常常聽到「區塊鏈是一部 Trust Machine」這樣的說法,或者有人會說在區塊鏈的世界裏是「In Math we Trust」,可見密碼學對於區塊鏈技術來說是根基一樣的重要存在。

好了,那麼問題來了:

  • 區塊鏈究竟在哪些地方用到密碼學呢?
  • 密碼學爲什麼對區塊鏈技術至關重要?

區塊鏈的哪些地方用到了密碼學?

首先,如果你是一個區塊鏈用戶,可能在你房間裏的某個角落,會有一張紙條,上面抄着十二個不知道怎麼來的單詞,有的人還有很多張,甚至有些大 holder 會把這十二個英文單詞刻在鋼板上,然後鎖進保險箱裏。

是的,爲什麼這十二個助記詞,或者像一長串亂碼般的私鑰能夠代表你對資產的所有權呢?

這背後的原理其實就是密碼學。

區塊鏈上的密鑰、地址和錢包都是通過密碼學去實現,利用非對稱加密技術——橢圓曲線算法(ECC)可以驗證某人持有的私鑰是否是吻合某個公鑰,通過這個方式我們可以證明這個人是否是這筆加密資產的持有人,因爲除了擁有私鑰的人之外,其他沒有該私鑰的人是沒有辦法解鎖這筆資產的。

我們在此用比特幣舉例私鑰、公鑰和地址生成的原理,一個比特幣錢包中包含一系列的密鑰對,每個密鑰對包括一個私鑰和一個公鑰。私鑰通常是一個隨機選出的 256 位的數字。基於私鑰,我們就可以使用 secp256k1 標準的橢圓曲線這個單向密碼函數產生一個公鑰。基於公鑰,我們又可以使用一個單向哈希函數 SHA256 和 RIPEMD160 生成比特幣地址,再通過 Base58 check 編碼將比特幣地址變成現在這較爲簡潔的形式。而像我們比較常用的助記詞,則是通過基於 BIP 39 標準而生成的隨機英文單詞。如果沒有私鑰或助記詞的人,是無法使用這筆加密資產的。

比特幣的公鑰和地址的生成過程,圖取自精通比特幣

當我們有了可以配對的密鑰對後,可以在各種類型的錢包或者客戶端上做驗證,確認資產的所有權,並且通過這個客戶端來進行各種資產的使用。例如最簡單 BTC 轉賬,或者再進階一點的用某個錢包去簽署智能合約的交易:比如用 Metamask、imToken 或者 Alphawallet 等錢包裏的 ETH 去購買加密貓,或者在 DeFi 的平臺上面進行借貸,以及用 Uniswap 交換某些 ERC20 Token 等。

除了轉賬等基本的驗證外,現在甚至某些平臺的身份驗證都可以用公私鑰來做登錄驗證,或者通過驗證你是某筆資產的所有人來進行各種權益的證明。簡單來說,公私鑰驗證系統背後的密碼學就是用戶想暢遊區塊鏈世界的通行證 。

在區塊鏈中,還有另外一個不可忽視的密碼學使用場景,就是區塊中的交易排序 ,以及 Merkle Tree 等決定區塊排序的過程。比特幣就是將每筆交易用 SHA256 算法進行加密,在這裏加密算法確保了區塊鏈的安全性,以及幾乎不可能被篡改的特性。光是在這兩個比特幣的基礎使用場景中就都用到了密碼學,於是乎甚至還有許多人在猜測,中本聰可能是個密碼學大佬,才能夠把密碼學在這個點對點的現金系統中使用的淋漓盡致。

當然,除了在區塊的生成和公私鑰驗證這兩大區塊鏈的核心功能上可以發揮用途之外,密碼學在隱私保護甚至擴容等方面都可以派上用場。

現在的公鏈如何使用密碼學?

  • Wow,這是一條新的公鏈嗎?
  • 那它有沒有錢包啊 ?
  • 又要多一組新地址和抄一組新的助記詞了。。。

如果一個用戶真的願意自己好好地保管自己的資產,也勤於投資不同的公鏈,我相信他們一定也會有類似的經驗和好幾組不同的助記詞或私鑰。但到最後,他們能夠保存好的,可能只剩下那些最主要的持倉資產,有些人甚至忘記備份某些資產的助記詞。

長期下來,區塊鏈資產管理的問題也導致區塊鏈的門檻越來越高。所以一些錢包爲了解決這個問題,已經提出了很多的優化方案。有些錢包甚至可以做到一個身份錢包的單一助記詞,可以管理多種資產等功能,但仍然有許多組不同的地址必須要由用戶來做管理。這樣的問題對於很多新公鏈而言可能更爲嚴重,因爲如果用戶要去通過他們的網頁或手機錢包,去嘗試鏈上的應用,用戶就會增加許多管理公私鑰的成本,更何況他們不像郵箱的密碼一樣可以任由用戶自己定義,既不滑順也不香。

但爲什麼區塊鏈會有這樣的限制?

這樣的限制是因爲目前許多的公鏈,都將很多密碼學原語的使用場景寫入了共識層,因此在這些公鏈中,像公私鑰簽名、客戶端驗證,以及區塊生成的哈希和常用的加密算法,基本上都是鑲嵌在共識層中的。例如地址所使用的驗證、交易使用的簽名等,其實都寫在底層協議中,因此會變得非常難以改動。另外,許多公鏈的虛擬機性能都不足以支持靈活的密碼學原語部署,因此對於這樣的公鏈而言,如果底層的虛擬機不預先支持某個密碼學原語,那麼基於該密碼學原語的場景可能很難直接被開發者使用。

如果要更動,唯一的辦法就是硬分叉!

拿以太坊爲例,以太坊的共識層寫入了哪些密碼學的場景呢?

除了區塊的加密簽名和 Merkle Tree 的哈希外,還有交易簽名和客戶端的驗證。如果有任何人想要在這些點上做改動,例如將以太坊公私鑰的哈希算法 keccak-256 換成其他簽名算法,那麼唯一的辦法就是提一個 EIP (Ethereum Improvement Proposal),然後等待、祈禱這個提案被排入硬分叉之中。因爲寫在協議層的內容,就是全網的所有用戶都必須遵從的規則。

然而硬分叉往往需要非常長的時間,以 EIP 152 爲例,這是一個 2016 年就提出的提案,希望將簽名算法 BLAKE2 加入以太坊中,但直到 2019 年底的伊斯坦布爾提案中才被加入到升級的內容當中,整整歷時 3 年之久

從剛纔 EIP 152 的例子中我們還會發現另一個限制,那就是在以太坊上如果要使用虛擬機不支持的密碼學原語,幾乎是不可能的。因爲對於以太坊虛擬機而言性能是一大限制,光是簡單的運算,就能夠消耗大量的 gas。

因此我們如果回顧以太坊上歷次的分叉,就可以發現從家園(HomeStead)的硬分叉升級開始,以太坊就不斷地把所有可能常用到的密碼學原語,例如 sha256 hash、ripenmd160hash 等持續的通過預編譯(precompiled)的方式,加入到底層的虛擬機中。這點在拜占庭(Byzantium)或者伊斯坦布爾(Istanbul)的升級中也可以看到。以太坊通過硬分叉的形式,來預編譯密碼學原語以及這些密碼學原語運算的 gas 定價。

如果不通過預編譯合約在節點先進行實現,那麼許多簽名算法的智能合約部署將花費非常非常高的 gas 費,導致其根本無法部署。例如 EIP 196、 EIP 197 之所以被採納,就是預見了 zkSNARK 需要大量的 gas 進行鏈上的運算。因此預先將這些加密算法,如橢圓曲線加法、乘法和配對驗證等編譯進了底層的 EVM 中,好讓這些計算成本可以節省下來。所以,我們可以說在以太坊上除了已經做了預編譯的簽名算法外,其餘的加密算法基本上是沒辦法使用的。

上述這些固化的密碼學使用方式,對於開發者而言是一個很大的限制。

由於交易和客戶端的簽名驗證都被寫入共識層,因此驗證工具和流程都必須按照規定的加密算法進行。例如在比特幣或以太坊中,如果我們要創建一個賬戶,那麼我們依舊需要管理一組新的密鑰對。

對於想要帶來良好用戶體驗的開發者而言,這樣會產生很多的限制,並且需要通過其他方式,去彌補固化的底層設施帶來的不友善的用戶體驗。比如在創建助記詞之後,我們可以在某些錢包中使用 FaceID (如 imToken),比如在 ABC Wallet 中,用戶起初只需要靠像手機裏的六字驗證碼就能夠登入,等你真的覺得你需要把私鑰或助記詞導出了,再進行導出和備份。

這些都是開發者試圖提升用戶體驗所想出來的好辦法,但對於每一條新的公鏈,密鑰對管理的本質都是需要有一組新地址和密鑰,這個問題是一直存在的。

上述的公私鑰驗證方式不夠靈活的問題,在比特幣、以太坊等較爲先發的公鏈上或許還不明顯,因爲他們已經有既有的用戶,這些用戶也被折磨習慣了。但對於近期興起的公鏈而言,如果還存在和先前公鏈同樣的進入摩擦成本,那麼就是給用戶設置了障礙,也會影響開發者是否想要在這個公鏈上開發的意願。

一個對用戶有學習成本的公鏈,在獲取用戶上就存在着先天的壁壘,即使這些公鏈有其他的亮點,可能對於開發者而言,也不會那麼有吸引力,因爲他們知道很多的用戶可能都被這些不友善的用戶體驗給嚇走了。

另外,密碼學原語不能夠靈活使用的問題,影響的層面還不止於公私鑰的保存。對於開發者而言,如果以後他們想用更先進的密碼學原語來保證隱私及安全,一樣會面臨到底層的虛擬機能不能部署,以及支持簽名驗證的挑戰。當然還會影響目前大家討論的很熱的話題:跨鏈,因爲不同的鏈使用的密碼學原語也會有所不同,在虛擬機驗證交易時就會遇到這個難題,這也是爲什麼目前許多同構跨鏈的解決方案(Cosmos / Polkadot )可行,但對於異構跨鏈的方案卻停滯不前的原因。

Nervos 的設計有何不同?

在 Nervos CKB 中,除了交易排序外,沒有其他硬編碼的密碼學原語,資產所有權的驗證是通過 cell 中的 lock script 來做驗證,其中的驗證規則和使用的密碼學原語都是可以自定義的,因此幾乎所有的密碼學原語都可以被開發者靈活的使用。

套用一句 Nervos 研究員 Cipher 老師的話來說,就是:「在 CKB 上除了最基礎的交易排序以外,其餘都是應用層的內容。」這讓開發者擁有了非常大的開發彈性,去進行各式各樣的開發,例如更自由的賬戶驗證方法等。

因爲在基於 RISC-V 的 CKB-VM 中,要求的就是一套能夠符合 RISC-V 編碼的驗證規則而已,開發者有很多能夠自由揮灑的空間。下圖可以看出 Nervos 和其他可以支持智能合約的公鏈在靈活度上的差異,應用層的內容表示的是可以去做自定義的,協議層代表的是需要經過「分叉」才能改動的內容。

以目前 Nervos 的 Grnats 團隊 Lay2 爲例,爲什麼他們開發的 pw-sdk 能夠用以太坊的地址,甚至是 ENS 來接收 CKB?是因爲在 CKB 上,地址是開發者可以任意把玩的應用層內容。理論上只要鏈上有已經有驗證規則的 cell 和非對稱加密的加密算法庫,這種地址生成規則就能夠被驗證。例如我們可以把以太坊的 Keccak-256 (SHA-3)的簽名算法和驗證規則和比特幣的 SHA-256 都部署在鏈上,那麼未來的其他開發者就可以用 cell deps 進行調用。

也因此,任何的開發者未來如果想在 CKB 上 ,爲他的資產添加更先進的加密算法做爲解鎖的規則,是完全可行的。因爲任何人都可以部署各種密碼學原語庫在 CKB 上,並且可以通過優化去節省存儲空間以及減少驗證所需的 cycle 去降低部署的成本,讓任何先進的密碼學原語不用等到硬分叉也能夠被使用。

在 CKB 上可能看見的區塊鏈未來:直逼互聯網的用戶體驗

基於靈活的密碼學原語,我們可以說在未來,很多互聯網上用戶非常習慣的驗證規則,也完全可能被寫成 RISC-V 可以讀取的形式,並且被部署到鏈上,例如 PGP Key 驗證或者指紋解鎖等功能。如果在鏈上有一個能夠對應他們所使用的驗證標準的腳本,並且有可以支援這種驗證的可信環境,那麼如此方便的使用方式在未來是真的可能實現的。

再更深入一點地看,未來的應用層,會有更多的場景會使用到密碼學的各種算法。

近兩年在分層擴容的領域(Layer 2),除了原先的閃電網絡、狀態通道以及其他的側鏈解決方案之外,又出現了一種新興的密碼學擴容應用:Rollup,也就是利用簽名算法來壓縮交易。

目前在 Rollup 上最主流的壓縮交易的方式是零知識證明 (zkp),也就是所謂的 zkRollup。未來如果在 Rollup 上有其他更先進的零知識證明解決方案,或者利用其他去簽名算法(如 BLS 等),對於 CKB 而言,只要開發者可以想到低成本的實現方法,都可以直接讓 CKB-VM 驗證,而不需要通過硬分叉。因爲這並不涉共識層的內容,而且 CKB-VM 相較於 EVM 而言也更加地高效。目前安比實驗室也在開發在 CKB 上可使用的零知識證明庫,未來可供開發者任意使用。

另外,CKB 因爲可以支持靈活的密碼學原語,也在區塊鏈跨鏈資產轉移方面,比其它的公鏈有更大的先天優勢進行來自不同鏈的交易驗證,讓 CKB 更有機會完成異構跨鏈的資產流通與轉移。

打從中本聰的比特幣白皮書問世開始,區塊鏈就是一個可以在中心化的環境下用密碼學去證明共識的新技術,這是在互聯網上無法完成的事情。但要大規模的使用區塊鏈,我們要做的不是讓用戶在體驗上委曲求全,而是像 Lay2 團隊的 Frank 說的那樣:「我們需要一個能夠有能力去支持開發者‘開門迎客’的基礎設施」,讓區塊鏈不會因爲底層設施的不靈活,而成爲少數極客或圈內人的玩物。

公鏈如果能夠靈活的支持各種密碼學原語,讓開發者可以有更高的彈性,那麼就更可以跳過「教育用戶」的這個緩慢的過程。因爲就和互聯網一樣,雖然現在大家都是無網不歡的人,但對於純粹的 C 端用戶而言,他們依舊不需要知道互聯網到底分了幾層,或者 P2P 網絡是怎麼回事。

同樣的,區塊鏈的純 C 端用戶在使用區塊鏈技術時也不需要知道區塊鏈的底層知識,我們要做的是打造一個可以擁有互聯網體驗,又有區塊鏈的憑證,以及安全和去中心化等加成效果的基礎設施 ,而具有高度編程靈活性的 Nervos CKB 正在這條道路上奮勇向前!

感謝 Lay2 的知縣,SECBIT 的志鵬,史迪仔等人對本篇文章的意見和啓發。

Source:

https://ethresear.ch/t/when-do-we-need-cryptography-in-blockchain-space/7450

https://github.com/ethereum/go-ethereum/blob/a5eee8d1dc61352c29b9800eaf96609ba4184fd6/core/vm/contracts.go

https://medium.com/cryptocow/%E4%BB%A5%E5%A4%AA%E5%9D%8A-istanbul%E7%A1%AC%E5%88%86%E5%8F%89%E5%85%A7%E5%AE%B9%E4%BB%8B%E7%B4%B9-4e0a37fa420c