IPFS 技術評論

作者: fiatjaf https://fiatjaf.com/d5031e5b.html

IPFS的破損設計 #

2020-01-20

我曾經上過這個關於 “內容-地址 “的當。它聽起來非常好。你知道某個文件的存在,你知道可能有人擁有它,但你不知道它在哪裏,或者它是否被託管在某個域名上。有了內容尋址,你可以只說 “開始”,下載就開始了。你不需要關心。 其他解決常見難題的神奇屬性:網頁不會下線,鏈接不會中斷,有價值的內容總能找到它,其他人會爲你分發你的網站,任何內容都可以很容易地傳送給你附近的人,任何人都不必依賴第三方集中式服務器。 但你知道嗎?說一件事是好的並不自動使它成爲可能和有效運轉。例如:說東西是由他們的內容來解決的,並不能改變互聯網是 “location-addressed”的事實,你仍然必須知道擁有你想要的數據的peers在哪裏,並與他們連接。

這方面的解決方案是什麼呢?一個DHT!

DHT? #

事實證明,DHT的激勵結構很糟糕(正如你所期望的那樣,沒有人願意免費持有和提供他們不關心的數據給別人),而且IPFS的經驗證明,即使在像今天的IPFS這樣的小網絡中也是行不通的。 如果你運行過IPFS客戶端,你會注意到它是多麼的堵塞你的電腦。也許你不知道,如果你很有錢並有一臺非常強大的電腦,但是,它仍然不適合在整個世界上運行,也不適合在網頁、服務器和移動設備上運行。我想象可能有很多未優化的代碼和技術債務造成了這些和其他問題,但DHT肯定是其中最大的一部分。IPFS在默認情況下可以打開多達1000個連接,並吸走你所有的帶寬–而這僅僅是爲了與其他DHT Peers 交換密鑰。

即使你在 “客戶端 “模式下限制了你的連接,你仍然會被那些不明連接所淹沒–而且把IPFS節點作爲客戶端運行是沒有意義的,這違背了讓每個人託管他們所擁有的文件和內容尋址的整個目的,使網絡中心化,使IPFS補創建時要取代的對立的客戶端/服務器出現了。

連接? #

因此,DHTs對於一個計劃成爲大的和星際的網絡來說是一個致命的缺陷。但這並不是唯一的問題。 在IPFS上尋找內容是有史以來/最慢的體驗,而且由於某些我不理解的原因,下載的速度更慢。即使你在另一臺有你需要的內容的機器的同一局域網內,仍然需要幾個小時來下載一些你用=scp=幾秒鐘就能完成的小文件–這是考慮到IPFS設法找到另一臺機器,否則你的命令就會被卡住好幾天。

現在,即使你忽略了IPFS對象應該是可尋址的內容而不是可尋址的位置,並且知道哪個peer有你想要的內容,你去那裏並明確告訴IPFS直接連接peers,也許你可以得到幾秒鐘的(緩慢的)下載,但隨後IPFS將放棄連接,下載將停止。有時–但並不總是–將peer地址添加到你的引導節點列表中是有幫助的(但注意這根本不是你應該做的事情)。

IPFS應用程序? #

現在考慮一下IPFS的營銷方式:它告訴人們在IPFS上建立 “應用程序”。它贊助在IPFS之上的 “數據庫”。它基本上把自己宣傳成一個這樣的地方:開發者只要把他們的應用程序連接到那裏,所有的用戶就會自動地相互連接,數據將被保存在他們之間的某個地方,並立即可用,一切都將以點對點的方式工作。 除了它根本不是那樣工作的。“libp2p”,用於連接人們的IPFS庫,已經壞了,每6個月就會重寫一次,但他們保留了他們美麗的登陸頁面,說一切都神奇地運行着,你可以直接插入。我不是說他們應該讓一切都完美,但至少他們應該對他們真正擁有的東西誠實。

它不可能與其他人連接,多年來沒有js-ipfs和go-ipfs的互操作性(但他們卻宣傳將有python-ipfs、haskell-ipfs、whoknowswhat-ipfs),連接被切斷,還有許多其他問題。

因此,基本上所有的IPFS “應用程序 “都只是想連接兩個peer的應用程序,但不能手動操作,因爲瀏覽器和IPv4/NAT網絡沒有提供簡單的方法,WebRTC也很難,需要服務器。他們與 “內容尋址 “沒有任何關係,他們不是要建立 “Merkle樹的森林”,也不是要分發或存檔內容,以便所有人都能訪問。我不明白爲什麼IPFS把它的核心信息改爲這個 “全棧p2p網絡 “的東西,而不是基本的內容可尋址的想法。

IPNS? #

那數據庫呢?你怎麼能用一個應該改變的值來 “內容尋址 “數據庫?他們的方法是保存所有的值,過去的和現在的,然後用新的DHT條目來傳達什麼是最新的值。這就是IPNS。

顯然,就在提出了內容可尋址的想法之後,IPFS的人意識到這永遠無法取代正常的互聯網,因爲沒有人會知道存在什麼樣的內容,或者一些內容何時被更新–他們不想與正常的互聯網共存,他們想把它全部取代,因爲這個目標更大膽,可以獲得更多的資金,也許?

所以他們發明了IPNS,這個名稱系統將位置可尋址性重新引入本應只有內容可尋址的系統。

他們是如何做到這一點的呢?還是DHTs。它起作用了嗎?並非如此。它是有限的,緩慢的,比正常的內容尋址要慢得多,大多數時候它甚至在下班後都不工作。但是,儘管開發人員會告訴它還沒有工作,但IPFS的營銷人員會談論它,好像它是一個東西。

歸檔內容? #

我對IPFS的主要使用情況是存儲我個人關心的內容,以及其他人可能也關心的內容,比如來自死掉網站的舊文章和視頻,有時是在整個網站被撤下之前。 所以我就這麼做了。在許多個月裏,我把東西歸檔在IPFS上。IPFS的API和CLI並不容易追蹤東西的位置。=pin=命令也無濟於事,因爲它只是把你釘的哈希值扔在哈希值和子哈希值的海洋中,你再也找不到你釘的東西了。 IPFS daemon有一個假的文件系統,其功能半生不熟,但允許你在樹狀結構中通過名稱對事物進行本地定位。更新或添加新的東西非常困難,但還是可以做到的。它允許你給哈希值起名字,基本上。我甚至開始爲它寫一個包裝器,但在經過許多星期的精心策劃和分發後,我在假文件系統中的所有條目突然消失了。

儘管沒有丟失任何文件,但我還是失去了一切,因爲我無法在我自己的電腦中的哈希值的海洋中找到它們。經過一些挖掘和IPFS開發者的幫助,我設法恢復了一部分,但這涉及到黑客。我的東西消失的原因是假文件系統的一個錯誤。這個錯誤被修復了,但不久之後我又遇到了一個類似的(新)錯誤。在那之後,我甚至試圖建立一個哈希存檔和發現的服務,但由於上面列出的所有問題開始堆積,我最終放棄了。還有內容規範化的問題,IPFS daemon 用於通過HTTP提供默認HTML內容的代碼,IPFS瀏覽器擴展的問題以及其他問題。

面向未來? #

IPFS的核心宣傳特點之一是它使內容面向未來。我不確定他們是否使用了這種表達方式,但基本上你有內容,你對其進行哈希計算,你將得到一個永遠不會過期的地址,現在每個人都可以用同樣的名字來引用同樣的東西。事實上,這更好:內容被分割並在merkle-tree中的有哈希值,所以有細粒度的重複數據刪除,人們可以只存儲大塊的文件,當一個文件要被下載時,很多人可以同時提供它,像torrents一樣。

但接下來是協議的升級。IPFS使用了不同的哈希算法,不同的哈希格式,並將改變構建Merkle樹的默認算法,所以基本上相同的內容現在有大量可能的名稱/地址,這違背了整個目的,而且是的,使用不同策略哈希的文件並不自動兼容。 實際上,從一開始,merkle算法就可以由每個人在每個文件的基礎上進行改變(例如,你可以按章節或頁面而不是按字節塊來分割一個圖書文件)–儘管可能沒有人這麼做。我知道一開始就想出完美的合希策略是不容易的,但是處理這些問題的方式讓我懷疑IPFS的發起人並沒有真正擔心面向未來的問題,或者我們只是永遠處於Beta階段。

Ethereum? #

這也是一個大問題。IPFS是由Ethereum的愛好者建立的。我無法讀懂IPFS背後的人的想法,但我可以想象他們對激勵機制的理解和以太坊的人一樣差,他們傾向於類似於騙子的行爲,比如爲投資者獲得一大筆資金,以換取他們不知道能不能實現的承諾(比如Filecoin和IPFS本身),基於半真半假的說法,在中途改變東西,因爲一些高層管理人員決定要改變(動作快,破壞東西),用花哨的名字如 “分佈式網絡”。

他們把IPFS(這不是IPFS最初設計的主要內容)作爲 “點對點雲 “來推銷,對以太坊開發者來說非常有誘惑力,就像以太坊本身一樣:作爲一個爲你運行你的代碼的地方,這樣你就不必託管服務器或承擔任何責任,然後Infura將向所有人提供內容。同樣,Infura這幾天也在爲以太坊開發者免費託管和提供IPFS內容。具有諷刺意味的是,就像以太坊騙局一樣,隨着它越來越中心化,IPFS點對點網絡可能開始對終端用戶更好地工作。

IPFS的問題。太多的不可更改性 #

有了描述每塊內容的索引或數據庫,內容尋址就無法使用。由於IPFS是完全的內容尋址,除非你有一個非IPFS的索引或數據庫,或一個動態和可更新的鏈接的內部協議,否則什麼都不能做。

IPFS的自負使他們選擇了第二種方案,這被證明失敗。他們甚至鼓勵創建一個由IPFS驅動的數據庫,這不能不說是一種誤導。

2019-01-08

IPFS的問題-太多的不可改變性 #

有了描述每塊內容的索引或數據庫,內容尋址就無法使用。由於IPFS是完全的內容尋址,除非你有一個非IPFS的索引或數據庫,或者一個動態和可更新的鏈接的內部協議,否則什麼都不能做。

IPFS的概念使他們選擇了第二種方案,這被證明敗。他們甚至激勵創建一個由IPFS驅動的數據庫,這不能不說是一種誤導。

2019-01-08

IPFS問題-混亂 #

大多數IPFS開源項目、庫和應用程序(不包括Ethereum的東西)是嚴重依賴動態數據和臨時鏈接的東西。在關注IPFS社區時,你會看到最常見的項目是聊天室和類似的東西。我已經見過幾十個這樣的聊天室了。還有一個著名的由IPFS支持的數據庫。你怎麼能用內容尋址來做這些事情是個迷。當然,他們可能依賴於IPNS或其他外部地址系統。

在IPFS上還有一堆的 “文件共享”。人們用來臨時爲第三方提供一個文件的那種東西。在IPFS上有圖像共享,在IPFS上有粘貼式文件,等等。人們似乎並不認同這裏對斷裂鏈接的關注。

2019-04-28

IPFS問題-垃圾幣工廠 #

IPFS從一開始就被宣傳爲以太坊社區 “存儲 “數據的一種方式,用於他們的 “dApps”。我不認爲這在任何方面是有害的,但由於某些原因,它可能導致IPFS開發人員過多地關注Ethereum的東西。有一次我看了一個講座,顯示libp2p開發者–儘管被Ethereum團隊忽視了(最終創建了他們自己的不可知的p2p庫)–投入了大量的工作,讓一個在瀏覽器中運行的libp2p應用與一個正常的Ethereum節點對話。

總是有點被遺棄的 “Awesome IPFS “網站是一個大的 “dApps “庫,其中一些甚至沒有他們的登陸頁面了,還有無用的以太坊智能合約,出於某種原因使用IPFS來存儲他們的用戶產生的任何無用數據。 同樣,以太坊人使用IPFS本身並不是一個問題,但它至少是令人困惑的,也許是誤導,當你搜索IPFS時,大多數的使用案例實際上是以太坊的無用案例。

IPFS問題- 社區 #

直到昨天,我還是一個狂熱的IPFS用戶。很多時候,我問一些簡單的問題,而這些問題我在互聯網上找不到答案,在#ipfs Freenode上的IRC頻道。大多數時候我都沒有得到答案,即使我得到了答案,也很少是對IPFS有深刻了解的人。我曾經在js-ipfs倉庫中的問題被擱置了一年之久–其中一個問題是提高了人們對一個問題的認識,而這個問題在幾個月後通過完全重寫得到了修復,我在幾個月後意識到這一點後關閉了自己的問題,我認爲負責重寫的人從未承認他修復了我的問題。 幾天前,我問了一些關於IPFS協議內部如何工作的問題,真誠地想了解在IPFS上尋找和獲取內容的低效率。我指出,最好能有一張圖來顯示,這樣人們就會明白其中的困難(我沒有),也不會因爲速度慢而感到生氣。我被告知要閱讀白皮書。我已經看過白皮書了,但又讀了一遍相關部分。白皮書並沒有解釋任何關於DHT和IPFS如何尋找內容的問題。我在房間裏說了這一點,被告知要再讀一遍。 在有人誤讀這部分內容之前,我想說,我理解如果你忙於開發具有星際意義的東西,在IRC上不斷回答別人是一件很痛苦的事情,而且我沒有付錢給任何人,也沒有被回答的權利。另一方面,如果你正在開發一個超級重要的協議,由數百萬美元資助,很多人在你的軟件上撞得頭破血流,卻沒有人幫助他們;你總是很忙,卻從來沒有提供給你的用戶帶來快樂的東西,那麼事情就很不對勁了。我真誠地不知道IPFS的開發者在做什麼,如果他們這麼說,我不會懷疑他們在做重要的事情,但我看到的–以及許多其他用戶看到的(看看IPFS Discourse論壇)是bug,到處都是bug,混亂的用戶體驗,幾乎沒有幫助。

2019-02-14

IPFS問題- 釘 #

“Pin “是IPFS團隊想出的一個很好的詞,用來指定告訴你的節點永久地存儲一些內容,不要把它當作垃圾來收集。這個想法是,你將存儲你獲取的所有內容,並自動將這些內容轉發給其他人,但每隔一段時間,你的節點上所有沒有明確 “釘住 “的內容都將被刪除,所以你不應該擔心存儲太多的其他人的東西,但也可以爲保持你喜歡的內容而做出貢獻。

然而,“釘 “有一個很大的問題:你無法知道你釘了什麼。你添加的每一個釘子都會被保存在你的電腦上,你將無法取消釘子,因爲你不知道什麼是什麼,最後你會留下一個裝滿釘子的磁盤,在對整個IPFS實驗感到沮喪之後,你可能會失去這個磁盤,或者刪除所有東西,爲其他東西打開空間。

審視一下這個模型中的激勵機制:我們依靠的是分享是由人們在不情願和不知道的情況下做出的。用戶在節點上花費電力,而這些節點應該是一直在運行併爲他人提供內容的。只有當有人決定釘住它們時,鏈接纔會保持不中斷,但由於沒有秩序,釘子註定會被到處抹去。

2019-02-14

IPFS問題-自負 #

IPFS正試圖做許多事情。IPFS的領導者是革命者,他們認爲自己比整個行業的其他人都要聰明。

他們首先提出了一個用於點對點分發不可改變的、有內容地址的對象的協議,後來又試圖用他們自己的半生不熟的解決方案(IPNS)來解決同樣的問題,這是一個例子。

其他的例子是他們以一種非常不具體的方式呼籲去中心化,他們過度的與以太坊的調情和他們永遠無法完成的永遠無法工作的/Filecoin/項目。

他們本可以專注於通過哈希值(不是說這實際上是一個好主意,但它有一些潛力)在點對點網絡上分配對象的基礎設施,但在試圖重新發明整個互聯網時,他們把一切都搞砸了。

2019-01-10

IPFS的問題-效率低下 #

想象一下,你有兩個IPFS節點,並且在第一個節點上有由你創建的獨特內容。從第二個節點,你可以連接到第一個節點,一切看起來都很正常。然後你試圖獲取這些內容。幾秒鐘後,內容開始出現,進度條開始移動,這很慢,非常慢,做rsync會快20倍。

進度條停止了。你調查了一下,第二個節點沒有再連接到第一個節點。爲什麼,如果那是我們試圖獲取的文件的唯一來源?這至今仍是個謎。你手動重新連接,進度條再次移動,停止了,你又被斷開了。你沒有重新連接,而是決定將第二個節點添加到第一個節點的 “Bootstrap “列表中。

我曾經試圖在VPS上運行一個IPFS節點,並在S3上存儲內容。有兩個S3數據存儲插件可用。在修復了其中一個的一些問題後,重新編譯go-ipfs,弄清楚如何從IPFS配置文件中讀取設置,創建一個init profile並再次重新編譯,我得到了節點的運行。它成功了。我的想法是在這個節點上託管一堆數據。數據將按需從S3獲取,所以從任何IPFS節點或網關都可以廉價而快速地訪問它。 IPFS開始每分鐘對S3進行數百次調用–如果我沒有在插件代碼中插入一些日誌語句,我是說在AWS的鉅額賬單到來之前,我不會知道這件事。很明顯,這是參與DHT的一部分。調整一些設置後,我的節點按照我的意圖變成了一個只聽不看的東西,但我不是100%確定它能作爲一個有效的內容提供者工作,而且我永遠不會知道,因爲內存和CPU使用率對我簡陋的VPS來說變得太高了,我不得不把它關掉。

2019-02-14

IPFS問題-動態鏈接 #

內容可尋址性很酷,我們都喜歡它,但我們也都知道,我們不能生活在一個沒有可讀和可記的名字的世界裏。IPFS從一開始就提出了IPNS,即星際名稱系統(名字確實非常酷)(也許是在IPFS的第一個想法之後的幾個月,這將表明這個問題是事後纔想到的)。

有人說IPNS的工作方式類似於Git頭和分支(這可能是Juan Benet在最初幾年大量重複的營銷宣傳的一部分,即IPFS是Torrents、Git和其他一些很酷的技術的混合)。然而,這仍然是一個遙遠的承諾。在過去的幾年裏,IPNS一直是一種非常緩慢的、不被他們自己的開發者所推薦的、無法使用的處理內容的方式,基本上只是一個從公鑰到對象哈希的指針。 建議使用域名和dnslink,這是告訴IPFS節點你擁有一個域名的方法,可以用來識別一個對象哈希值。那是可行的,但它不是承諾的去中心化的奇蹟,而且,它仍然只是一個指針。任何鍵值存儲、文件系統的數據庫都可以做指針。


在這裏,我並不是說,像互聯網上大量愚蠢的人那樣,IPFS應該支持動態鏈接,這樣我們就可以在上面建立網絡應用。不,我只對靜態內容使用靜態鏈接就很好,而對需要動態的東西繼續使用其他互聯網協議。

2019-02-14

爲什麼IPFS不能成功,再次解釋 #

2021-05-13 https://fiatjaf.com/b8e2f959.html 想象一下,有人想出了一個P2P內容地址數據共享的解決方案,這個方案將所有文件的內容存儲在網絡的所有計算機中。這不可能實現,是吧?太多的數據,如果你認爲這可行,那麼你就像一個BSV愛好者。

然後有人想出了一個主意:不把所有的東西都存儲在所有的計算機上,而只把一些東西存儲在一些計算機上,根據一些算法和給定的pub key來確定一個節點 上會存儲什麼數據。這仍然行不通,是吧?不管如何這樣分散存儲,數據還是太多,主要是激勵措施沒協調好,所以第一天就會內爆。

現在想象一下,有人說他們將做同樣的事情,但不是存儲全部內容,而是每個節點只存儲一個指針,指向每個數據實際可用的地方。這是否使它變得更好?幾乎沒有。這只是在轉移問題。

這就是IPFS。

現在,你在每臺計算機上的數據減少了,但在全球範圍內,這仍然是一個很大的數據。

沒有激勵措施。

而且現在你有一個尋找數據的問題。首先,如果你有一些你想讓全世界都能訪問的數據,你必須廣播有關信息,讓這個信息充斥着網絡–而且每個人都必須爲每一個可用的文件(或文件碎片)不斷地做這件事。

然後,每當有人想要一些數據時,他們必須找到知道這些數據的人,這意味着他們將用請求充斥(flooding)整個網絡,在peer之間傳遞,直到他們到達正確的peer。

你越是強迫每個peer存儲,運行節點和代表他人存儲數據的情況就越糟糕–但你越是不強迫每個peer存儲,你在全球網絡上flooding就越多,任何人真正得到任何文件的速度就越慢。

但是,如果每個人都只是把所有的東西都保存到Infura或Cloudflare,那麼它就能運行了,真是魔幻的“去中心化”技術。