read.cash Log in
@liwi more from that month

關於 NFT 包含圖片通通上鏈(smartBCH)的三兩事 Oasis 釋出 Browse 功能後,IPFS gateway 的重要性應該算是被凸顯了。 Gateway 之外,IPFS 還有 pinning / garbage collection 的特性,不是傳上去就保證永續存續的。 最近參與製作了 Piccololi https://noise.cash/post/1rg6m3v5 一開始其實也是想說照公式(共識?)用兩層 IPFS 但後來基於一千零一個原因,決定嘗試全部打包上鏈這樣的設計。 其中一個最重要的因素(當然)是 Piccololi 的圖檔大小算是在可以接受的範圍 基本的 Piccololi 圖片火耗大概在 0.005 ether/BCH 特殊一點的則可以到 0.05 ether/BCH 一開始開發以 Rinkeby 為主要測試環境,那就會遇到以太坊 30 M 的 block gas limit 256 bit = 32 byte 要 20k gas 所以系列裡最大的圖檔加上其他有的沒的 overhead 吧,會沒辦法被包進單一區塊裡。 這也不是什麼硬性的限制,一個塊傳不完可以分兩個三個四個區塊包。 那因為 smartBCH 的 block gas limit 是 1B,所以原本想說這問題到了 smartBCH 就自動不存在了。 但事情往往不是憨人所想的那麼簡單。換到 Amber 測試環境後,非但系列裡可能出現的最大的圖檔沒辦法一次打包上鏈,連一些原本 Rinkeby 上的去的也吃癟。 打探之下才知道,smartBCH 目前還另外有 transaction gas limi,每一個交易至多 10M gas。 所以 Piccololi 最後就是摸摸鼻子做了分塊打包上鏈的機制。也不是什麼大事,就蠻意外的這樣。 所以把數字兜起來的話,smartBCH 出塊約是以太坊的 3倍速,每區塊的瓦斯容量則約是 33 倍,總和起來就是以太坊的 100 倍吞吐量,非常有比特幣現金一貫以來的訴求特質。 至於 100 倍是不是就足夠各門各類的 DApp 而不會如黑鴨說的一個熱門就塞車呢?這就有待各位去估算了。 那麼圖片上鏈是不是就避免了類似 IPFS 的 gateway 問題了呢?其實也沒有,只是 gateway 變成 rpc 而已。但 pinning / garbage collection 的問題則算是解決了,基本上是鏈在圖在,鏈亡圖亡。 smartBCH 白皮書裡就有提到 QPS,query per second 的概念並討論,指出如果 infura 掛點,那以太坊上的 DApp 大概就是先死機。Infura 外當然也還有其他 RPC,但重點或許可以解讀成,在一個以 peer-to-peer 為基礎的系統裡,每一個 peer,或大或小,都是重要的。 曾經有討論串指出,區塊鏈生態系最不重要的就是類樹莓派節點,因為在最長鏈共識上基本上沒有話語權。但從 QPS 的角度來看,就也未必盡然如此。即使沒辦法參與共識決,保持同步並提供網路容量還是非常有貢獻的一件事。 最後要來賣瓜:想要一個與 smartBCH 共存亡的 NFT 嗎?請持續關注 https://noise.cash/c/piccololi-nft-1zp4gvk1 ,公關活動就我理解會有 giveaway。

1 comment

Log in to join in Reading is open to everyone. Replying needs an account.