BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Trang chủ
AI AI
Tin nhanh
Bài viết
Sự kiện
BlockBeats Pro
Thêm
Thông tin tài chính
Chuyên đề
Hệ sinh thái chuỗi khối
Mục nhập
Podcast
Data
OPRR
Partnered With:

Bạn nghĩ gì về sự cố dịch vụ Infura và tác động của nó?

Đọc bài viết này mất 21 phút
Chúng ta nên mang lại cho các nhà phát triển khách hàng sự tin tưởng và tôn trọng hơn.
Tiêu đề gốc: "Bạn nghĩ gì về sự cố dịch vụ Infura và tác động của nó?" 》
Nguồn gốc: Những người đam mê Ethereum



Lịch sử sự kiện


Chiều ngày 11 tháng 11 năm 2020 theo giờ Bắc Kinh, Infura, một dịch vụ node nổi tiếng trong cộng đồng Ethereum, đã gặp phải lỗi dịch vụ API, khiến nhiều dịch vụ được xây dựng bị sập trên Infura. , hoặc màn hình hiển thị phía trước không chính xác.


Đối với bản thân Infura, nó có thể được hiểu là một nút Ethereum công khai, nút này sẽ nhận các yêu cầu và trả về một số dịch vụ nhất định, chẳng hạn như giúp chuyển tiếp giao dịch. , chẳng hạn như kiểm tra xem một giao dịch nhất định đã được tải lên chuỗi hay chưa hoặc trạng thái của tài khoản là gì. Trên thực tế, miễn là bạn tự mình triển khai nút Ethereum, bạn có thể cung cấp các dịch vụ tương tự như Infura. Nhưng điểm đặc biệt của nó là hầu hết các dịch vụ của Infura đều miễn phí, vì vậy nhiều dịch vụ (bao gồm cả sàn giao dịch) đã chọn dựa vào Infura để báo cáo trạng thái của chuỗi khối Ethereum cho chính họ, loại bỏ rắc rối khi tự triển khai các nút.


Chính vì lý do này mà nếu Infura mắc lỗi thì về lý thuyết sẽ có ảnh hưởng rất rộng, trong quá trình xảy ra sự việc, thậm chí có người còn đe dọa rằng "Ethereum sẽ phân nhánh (hoặc Một phân nhánh đang diễn ra)". Lý do là hai trình duyệt khối khác nhau (Etherscan và Blockchair) hiển thị hai khối khác nhau cho cùng một chiều cao khối (nhưng các khối sau hai khối này được hai trình duyệt hiển thị nhất quán).


Nhưng rõ ràng là Ethereum chưa hề phân nhánh. Trên thực tế, các khối tiếp theo được hiển thị bởi cả hai trình khám phá khối đều giống nhau, điều đó có nghĩa là những người khai thác đã tạo ra khối (ít nhất là hầu hết các thợ mỏ) đã không tiếp tục khai thác với hai khối khác nhau làm khối gốc, họ cũng không từ chối các khối của nhau. . Về mặt lý thuyết, một phân nhánh chỉ có thể thực hiện được nếu các nút tạo khối sử dụng các quy tắc đồng thuận khác nhau (và do đó từ chối các khối do bên kia tạo ra) và tất cả đều chiếm một lượng sức mạnh tính toán nhất định.


Trên thực tế, người ta nhanh chóng phát hiện ra rằng điều này là do Infura không chạy phiên bản mới nhất của ứng dụng khách Geth và một số giao dịch nhất định đã kích hoạt phiên bản này. Một lỗi trong khách hàng đã khiến nó bị hỏng. Điều tương tự cũng xảy ra với Blockchair. Vì vậy, ngay sau đó đã có người bước ra và kêu gọi mọi người nâng cấp ứng dụng khách Geth càng sớm càng tốt.


Tính đến 18:00 ngày 11, giờ Bắc Kinh, nhóm Blockchair Nikita Zhavoronkov@nikzh Đã đăng Twitter để giải thích nguyên nhân và ảnh hưởng của sự việc:


1. Một sự thay đổi mã nhất định của các nhà phát triển Ethereum đã dẫn đến sự phân chia chuỗi khối Ethereum vào ngày hôm đó. Sự phân chia bắt đầu ở độ cao khối 11234873;

2 . Các nhà cung cấp dịch vụ không cập nhật khách hàng của họ, bao gồm Blockchair và Infura, đã phải gánh chịu hậu quả và bị bỏ lại trong một chuỗi gồm một số ít người (chuỗi sản xuất 30 khối trong 2 giờ)

3 . Về mặt kỹ thuật, điều này có nghĩa là đã xảy ra một "hard fork không báo trước"

4. Cách khắc phục là nâng cấp ứng dụng khách geth và chạy debug.setHead(11234872)


Ông cũng nói rằng không bao giờ nên đánh giá thấp sự cố này và nên được coi là sự cố nghiêm trọng nhất trên blockchain Ethereum sau sự cố The DAO. .


Thật kỳ lạ, tại sao lại có một lỗi nào đó chỉ khiến phiên bản lịch sử của phần mềm bị lỗi trước một thời gian nhất định mà phiên bản hiện tại thì không? Điều này không có nghĩa là các quy tắc đồng thuận của các phiên bản khác nhau của ứng dụng khách geth thực sự khác nhau, tức là đã có sự thay đổi quy tắc đồng thuận ("hard fork") không tương thích ngược tại một thời điểm nhất định? Ngoài ra, sự cố của một chiếc Infura đã gây ra lỗi dịch vụ trên diện rộng, phải chăng điều này có nghĩa là Infura đã trở thành nguồn "điểm lỗi duy nhất"?


Lý do


Trả lời hai câu hỏi trên, trưởng nhóm khách hàng Geth  ;Péter Szilágyi@peter_szilagyi tất cả đã phản hồi.


-Về mặt kỹ thuật mà nói, Thực sự có thể nói rằng đã xảy ra một "hard fork không công khai", nhưng điều này chỉ là do các nhà phát triển đã sửa một lỗi đã không hoạt động trong hơn hai năm và vì họ lo lắng rằng việc tiết lộ công khai lỗi này sẽ dẫn đến việc Ethereum bị tấn công , vì vậy Sửa chữa im lặng đã được chọn.

-Mọi người không nên coi thường  Infura không sử dụng Geth mới nhất khách hàng. Từ quan điểm của nhà điều hành, việc không cập nhật các phiên bản phần mềm mới nhất là điều hợp lý. Khi bạn tin tưởng vào các dịch vụ của Infura, bạn giao quyền này cho chính mình chứ không phải người khác cấm bạn chạy các nút, vì vậy không có gì phải phàn nàn.


Câu trả lời của Peter cũng gây ra nhiều phản ứng trái chiều. Một người trong cộng đồng Monroe cho biết rằng vào năm 2017, họ cũng có mối lo ngại tương tự. Tôi đã chọn âm thầm sửa lỗi. Tất nhiên, một số người nghĩ rằng việc chọn sửa chữa im lặng là đúng, nhưng ít nhất cơ sở hạ tầng lớn nên được thông báo. Các nhà cung cấp, chỉ cần liên hệ với họ, có thể giảm đáng kể thiệt hại do lỗ hổng này gây ra.


Vào lúc 5:34 sáng ngày 12, giờ Bắc Kinh, Peter đã phát hành "Báo cáo khám nghiệm tử thi về thiệt hại do ứng dụng khách Geth v1.9.17 gây ra", xác định nguồn gốc của sự cố: Geth v1.9.7 phát hành vào ngày 7 tháng 11 năm 2019 triển khai không đúng EIP- 211; John Youngseok Yang đã báo cáo vấn đề này vào ngày 15 tháng 7 năm 2020, vì vậy nhóm Geth đã khắc phục vấn đề này trong phiên bản v1.9.17 được cập nhật vào ngày 20 tháng 7. Bản sửa lỗi này cho phép ứng dụng khách Geth nhất quán với các ứng dụng khách Ethereum khác (chẳng hạn như Besu và Nethermind) khi thực hiện các giao dịch liên quan đến các quy tắc có liên quan, nhưng nó khiến phiên bản v1.9.17 không nhất quán với các phiên bản lịch sử của Geth.


Như Peter đã nói, quá trình này hoàn toàn không nhằm đưa ra một quy tắc đồng thuận mà cộng đồng Ethereum không biết hoặc không đồng ý. Nó chỉ cần thiết vì có một lỗi được viết. Sửa lỗi. Trừ khi bạn gọi việc viết một lỗi là "hard fork", không có lý do gì để gọi việc sửa lỗi là "hard fork" (Nikita rõ ràng không đồng ý với điều này. Anh ấy nói rằng nó đã xảy ra hai lần ở đây, không phải một lần, hard fork) chéo).


Thứ hai, cách đưa ra bản sửa lỗi thực ra không hề đơn giản. Việc phối hợp hard fork của Ethereum cũng mất nhiều thời gian. Nếu một lỗi nguy hiểm nghiêm trọng được tiết lộ, không có gì đảm bảo rằng sẽ không có ai cố gắng tấn công nó trong quá trình nâng cấp của mỗi nút. Với tư cách là nhà phát triển ứng dụng khách, anh ấy nghĩ nhiều về tính bảo mật của mạng Ethereum hơn là tính bảo mật của một dịch vụ nhất định. Hơn nữa, họ không thực hiện các bản sửa lỗi im lặng giống nhau cho tất cả các lỗi, nhiều lỗi được sửa một cách công khai.


Vào lúc 7:11 sáng ngày 12, Jing từ nhóm Lạc quan đang tuyển dụng cho Optimism@jinglanW đã tiết lộ đã tiết lộ thêm thông tin: Họ đã tham gia 6 tháng trước, họ đã sao chép cơ sở mã của máy khách Geth để nghiên cứu và phát triển Máy ảo Optimistic, trong quá trình này, họ đã phát hiện ra một lỗi bí ẩn và sửa nó, nhưng họ không tìm được nguồn gốc của nó, họ luôn cho rằng lỗi này có thể liên quan đến Nó liên quan đến các cải tiến tùy chỉnh được nhóm giới thiệu, nhưng vào ngày 11, họ bắt đầu nghi ngờ rằng lỗi tồn tại trong phiên bản cũ của client geth, không phải do một số cải tiến mà họ đã giới thiệu. Vì vậy, sau khi họ xem xét phân phối nút hiển thị trên ethernodes.org (và nhận thấy rằng phần lớn các nút đã được nâng cấp), họ quyết định kiểm tra lỗi trên mạng chính. Do đó như sau.


Vì vậy, trên thực tế, nhóm Optimism đã phát hiện ra một lỗi và vội vàng quyết định kiểm tra xem lỗi đó có còn tồn tại trên mạng chính hay không. Ngoài ra, nhóm Geth đã có trước đó Lựa chọn sửa lỗi âm thầm gây ra lỗi trên một số nút không được nâng cấp kịp thời.


Chúng ta nên hiểu và nhìn vấn đề này như thế nào?


Xét về nguyên nhân cốt lõi của vấn đề, nguyên nhân là do nhóm khách hàng đã chọn cách âm thầm sửa một lỗi đã không hoạt động trong một thời gian dài. Trong khi nhiều người nghĩ rằng nhóm geth có thể giảm thiểu thiệt hại bằng cách liên hệ với nhà cung cấp cơ sở hạ tầng, ở đây tôi vẫn tin rằng chúng ta nên dành nhiều sự tin tưởng và tôn trọng hơn cho các nhà phát triển khách hàng. Tôi tin rằng nhóm khách hàng Geth làm điều này là có lý do, họ biết rằng hầu hết các nút đang sử dụng phần mềm của riêng họ và họ cũng tính đến thời gian ngủ của lỗi nên đã chọn cách âm thầm sửa lỗi. Từ góc độ nhận thức muộn màng, tất nhiên sẽ tốt hơn và ít gây rối hơn nếu thông báo trước cho các nhà cung cấp cơ sở hạ tầng lớn. Nhưng việc soi mói này có hợp lý không? Tại sao các dịch vụ phụ thuộc vào Infura không cho rằng Infura có thể gặp sự cố?


Tôi thừa nhận ở đây tôi không công bằng lắm, nhưng nhiều người đã nói những lời công bằng hơn. Tôi chỉ muốn bày tỏ sự tôn trọng của mình đối với nhóm khách hàng geth. Tôi sẵn sàng đưa ra ấn tượng của mình cho họ vì trước đây họ đã cung cấp rất nhiều bằng chứng về công việc. Họ xứng đáng được mọi người tôn trọng.


Tất nhiên vẫn còn chỗ cần cải thiện trong việc thực hiện các biện pháp sửa chữa thầm lặng và chúng ta nên học hỏi kinh nghiệm của cộng đồng Monero và Bitcoin. Nhưng nếu bạn chỉ nghĩ đến việc lên án nhóm geth, hay thậm chí suy đoán họ bằng những thuyết âm mưu thì đó sẽ là một sự bất công lớn hơn.


Về phần "liệu Infura có trở thành nguồn gốc của sự thất bại duy nhất hay không", cũng có những câu trả lời đơn giản và những câu trả lời phức tạp. Câu trả lời ngắn gọn là không, bởi vì như Peter đã nói, không ai cấm bạn triển khai các nút, chỉ là nhiều nhà cung cấp đã chọn tự thuê ngoài. Infura không phải là điểm duy nhất bạn phải trải qua ở cấp độ thiết kế. Chỉ vì nhiều lý do, nó có lẽ đã trở thành nhà cung cấp dịch vụ nút lớn nhất.


Nhưng câu trả lời phức tạp là mức tiêu thụ tài nguyên của các nút Ethereum tương đối lớn và đây thực sự là một vấn đề bị đánh giá thấp. Hoạt động của giao thức Ethereum yêu cầu mỗi nút phải thực hiện đầy đủ các giao dịch có trong khối. Để thực hiện giao dịch, dữ liệu phải được lấy từ dữ liệu trạng thái và kết quả phải được ghi sau khi hoàn thành. Quá trình này sẽ liên quan đến một lượng lớn đọc và ghi ngẫu nhiên trên đĩa cứng. Hơn nữa, khi khối lượng dữ liệu trạng thái mở rộng, yêu cầu về hiệu quả cho việc đọc và ghi cũng sẽ tăng lên. Vấn đề "lạm phát nhà nước" được thảo luận sôi nổi trong vài năm qua vẫn chưa được giải quyết trên Ethereum hiện tại. Ngưỡng để chạy các nút cao và số lượng nút đương nhiên là nhỏ. Từ góc độ có thiện chí, nếu ngưỡng hoạt động của các nút Ethereum bị hạ xuống, tôi tin rằng sẽ có nhiều người xây dựng các nút của riêng họ (xét cho cùng thì an toàn hơn) thay vì dựa vào Infura.


Nhưng giải pháp cho vấn đề này còn phụ thuộc vào trí tuệ của các nhà nghiên cứu và phát triển ứng dụng khách Ethereum. Không quốc tịch có thể nói là giải pháp tối ưu cho vấn đề mở rộng nhà nước. Trước khi giải pháp tối ưu trở nên khả thi, chúng tôi vẫn cần các nhà phát triển khách hàng đóng góp những khách hàng hiệu quả hơn cho chúng tôi.


Vì vậy, điều gì đó đã xảy ra, nó đã bộc lộ một số vấn đề và chỉ ra phương hướng cho việc học tập và tiến bộ của chúng tôi. Nhưng việc giải quyết những vấn đề này không thể tách rời sự hiểu biết và tôn trọng của chúng tôi đối với các nhóm khác nhau trong cộng đồng. Tránh xa các thuyết âm mưu, tránh xa những lời chế giễu ác ý và thông minh, tìm ra gốc rễ của vấn đề, suy nghĩ về bản chất của nó và các kế hoạch cải tiến. Những gì chúng ta làm quyết định chúng ta là ai.


Liên kết gốc


Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia

举报 Báo lỗi/Báo cáo
Chọn thư viện
Thêm mới thư viện
Hủy
Hoàn thành
Thêm mới thư viện
Chỉ mình tôi có thể nhìn thấy
Công khai
Lưu
Báo lỗi/Báo cáo
Gửi