Beep, beep, beep. Beep, beep, beep.

Giấc ngủ của Steven bị đánh thức bởi âm thanh chuông điện thoại khắc nghiệt, kéo anh ta đột ngột từ giấc mơ của mình. Trên bóng tối, màn hình phát sáng rực rỡ, rung rinh mạnh mẽ trên bàn đầu giường của anh ta. Beep, beep, beep. Anh ta rên rỉ, ngái ngủ chà xát mắt, và vươn tay lấy thiết bị. Nhìn chằm chằm vào tin nhắn, trái tim anh chìm sâu - node bị ngừng hoạt động. Không do dự, anh ta nhảy ra khỏi giường, một nửa mặc quần áo, lung lay để mở khóa điện thoại khi thêm tin nhắn tràn vào. Rồi nó đánh anh ta - toàn bộ cụm máy đều ngừng hoạt động.

Tại khoảnh khắc này, trên khắp thế giới, tại các thành phố và múi giờ khác nhau, hàng trăm nhà vận hành nút đang nhìn chằm chằm vào điện thoại của mình với cùng một nhận thức: Khoảnh khắc mà họ đề phòng đã đến - một sự cố.

Giới thiệu

Tương tự như tất cả các hệ thống phân phối khác, Solana hoạt động dưới sự thực tế rằng một lỗi triển khai duy nhất hoặc trường hợp cạnh biên mờ nhạt có thể dẫn đến sự cố trên toàn mạng. Các sự cố mất điện, mặc dù gây khó chịu, nhưng là một phần tất yếu trong việc duy trì cơ sở hạ tầng phân phối phức tạp—cho dù là trong chuỗi khối phi tập trung, các sàn giao dịch tập trung, hoặc thậm chí là các nhà cung cấp dịch vụ đám mây lớn như Amazon hoặc Microsoft.

Câu hỏi không phải là khi sự cố xảy ra, mà là khi nào - và cách mạng lưới phát triển để thích nghi và làm cứng chính nó trước các sự cố tương lai. Mặc dù đã có các bài kiểm tra mô phỏng nghiêm ngặt, một mạng lưới thử nghiệm được khuyến khích và một chương trình thưởng lỗi hoạt động, không có hệ thống nào - dù có thiết kế tốt đến đâu - có thể dự đoán mọi chế độ sự cố có thể xảy ra. Những bài học quý giá nhất đến từ hoạt động trong thế giới thực.

Trong năm năm qua, Solana đã trải qua bảy sự cố ngừng hoạt động riêng biệt, năm trong số đó là do lỗi của khách hàng và hai do mạng không có khả năng xử lý lũ lụt thư rác giao dịch. Các phiên bản đầu tiên của Solana thiếu các cơ chế quản lý tắc nghẽn chính, chẳng hạn như phí ưu tiên và thị trường phí địa phương, sau này tỏ ra cần thiết trong việc giảm thiểu căng thẳng mạng. Việc thiếu các cơ chế như vậy đã dẫn đến thời gian hiệu suất xuống cấp và tắc nghẽn kéo dài trong suốt năm 2022 vì mạng về cơ bản khuyến khích thư rác.

Các trường hợp lịch sử về sự cố ngừng hoạt động của Solana và hiệu suất giảm sút

Bài viết này sẽ phân tích chi tiết từng sự cố ngừng hoạt động của Solana, kiểm tra nguyên nhân gốc rễ, các sự kiện kích hoạt và các biện pháp được thực hiện để giải quyết chúng. Ngoài ra, chúng tôi sẽ thảo luận về các khía cạnh chính của việc khởi động lại mạng, báo cáo lỗi và các khái niệm cơ bản về sự sống và lỗi an toàn. Mặc dù các phần này được đọc tốt nhất theo thứ tự, mỗi phần được thiết kế để đứng một mình, cho phép người đọc chuyển sang các chủ đề hoặc sự cố mất điện mà họ quan tâm nhất.

Sự Sống và An Toàn

Theo định lý CAP, còn được gọi là Định lý Brewer, một hệ thống phân tán chỉ có thể đạt được hai trong ba đặc tính:

• Tính nhất quán - Mọi lần đọc đều thấy tất cả các lần ghi trước đó.
• Sẵn có - Mọi yêu cầu đều nhận được phản hồi.
• Tolerance phân vùng - Hệ thống tiếp tục hoạt động mặc dù có các phân vùng mạng.

Đối với blockchain, dung sai phân vùng là điều cần thiết — sự gián đoạn mạng là không thể tránh khỏi. Điều này buộc phải lựa chọn giữa AP (Tính khả dụng + Dung sai phân vùng) và CP (Tính nhất quán + Dung sai phân vùng). Giống như hầu hết các chuỗi PoS cuối cùng nhanh, Solana ưu tiên tính nhất quán hơn tính khả dụng, biến nó thành một hệ thống CP. Nó dừng lại trong các lỗi nghiêm trọng thay vì phục vụ dữ liệu cũ hoặc cho phép ghi không an toàn. Mặc dù điều này có nghĩa là phần mềm nút có thể chuyển sang trạng thái không thể khôi phục được yêu cầu can thiệp thủ công, nhưng nó đảm bảo tiền của người dùng vẫn an toàn.

Vị trí của Solana trong việc cân nhắc đổi lấy giữa ba yếu tố của định lý CAP

Lỗi tính sống: xảy ra khi blockchain ngừng tiến triển, ngăn chặn giao dịch được xác nhận và các khối được tạo ra do thời gian chờ của người xác nhận, phân vùng mạng, hoặc sự đình trệ của sự đồng thuận. Trong ngữ cảnh của định lý CAP, điều này tương ứng với việc mất tính khả dụng.

Lỗi An toàn: xảy ra khi trạng thái đã hoàn tất của blockchain bị thay đổi hoặc fork một cách không đúng. Điều này có thể dẫn đến lịch sử mâu thuẫn hoặc chi tiêu kép, thường do lỗi đồng thuận hoặc tấn công độc hại. Trong ngữ cảnh của định lý CAP, điều này tương ứng với việc mất tính nhất quán.

Solana ưu tiên sự an toàn hơn sự sống động. Do đó, mạng sẽ dừng trong trường hợp căng thẳng mạng cực độ hoặc lỗi đồng thuận thay vì rủi ro tham nhũng nhà nước. Mặc dù sự cố ngừng hoạt động gây gián đoạn và có thể ảnh hưởng đến các ứng dụng, người dùng và trình xác thực, nhưng chúng thích hợp hơn với hậu quả thảm khốc của sổ cái không nhất quán hoặc bị hỏng.

Khởi động lại mạng

Khởi động lại mạng Solana liên quan đến việc xác định khe cắm khối được xác nhận một cách lạc quan cuối cùng và khởi động lại các nút từ một bản chụp trạng thái cục bộ đáng tin cậy của khe đó. Khi khe khởi động lại không được xác định trên chuỗi, các nhà điều hành xác nhận phải đạt được sự đồng thuận ngoại chuỗi để đồng ý với điểm quay trở lại an toàn. Sự phối hợp này diễn ra công khai trong kênh #mb-validators trên Solana Tech Discord, nơi các nhà điều hành xác nhận chuyên nghiệp giao tiếp trong thời gian thực. Hầu hết các nhà điều hành có hệ thống cảnh báo tự động thông báo cho họ ngay lập tức khi sản xuất khối ngừng lại, đảm bảo phản ứng nhanh chóng.

Khi đạt được sự đồng thuận về vị trí khởi động lại chính xác, các nhà khai thác sử dụng công cụ sổ cái để tạo ảnh chụp nhanh cục bộ mới, khởi động lại trình xác thực của họ và đợi ít nhất 80% tổng số cổ phần trở lại trực tuyến. Chỉ sau đó, mạng mới tiếp tục sản xuất và xác thực khối. Việc xác minh rằng có tối đa 20% cổ phần ngoại tuyến khi cụm khởi động lại đảm bảo đủ biên độ an toàn để duy trì trực tuyến trong trường hợp các nút phân nhánh hoặc quay lại ngoại tuyến ngay sau khi khởi động lại.

Báo cáo lỗi

Các chương trình tiền thưởng lỗi thưởng cho các nhà nghiên cứu bảo mật vì đã xác định và báo cáo các lỗ hổng phần mềm. Đây là một tuyến phòng thủ quan trọng, vì nó chủ động khuyến khích bắt lỗi trước khi chúng có thể bị lợi dụngCác nhà nghiên cứu bảo mật và nhà phát triển nếu phát hiện ra các lỗ hổng tiềm năng trong Agave client được khuyến khích báo cáo chúng qua các kênh bảo mật thích hợp.Hướng dẫn tiết lộ chi tiết có thể được tìm thấy trong kho lưu trữ Agave GitHub.

Phần thưởng được cung cấp cho các báo cáo hợp lệ về các lỗ hổng quan trọng, với việc thanh toán dựa trên mức độ nghiêm trọng:

• Mất tiền: Lên đến 25.000 SOL
• Đồng thuận hoặc vi phạm an toàn: Lên đến 12.500 SOL
• Độ sống hoặc mất khả dụng: Lên đến 5.000 SOL

Ngoài ra client FireDancer có một chương trình thưởng bug riêngđược đặt qua Immunefi, cung cấp mức thưởng tối đa là $500,000 USDC cho các phát hiện quan trọng.

Phiên bản cúp điện

Các phần sau đây cung cấp phân tích chi tiết, theo trình tự thời gian về sự cố ngừng hoạt động của Solana và thời gian hiệu suất suy giảm, bắt đầu từ khi ra mắt Mainnet Beta vào ngày 16 tháng 3 năm 2020. Cuộc kiểm tra này sẽ làm nổi bật các sự cố chính, nguyên nhân gốc rễ của chúng và những cải tiến tiếp theo của mạng, cung cấp cái nhìn sâu sắc về cách Solana đã phát triển để tăng cường sự ổn định và khả năng phục hồi theo thời gian.

Turbine Bug: Tháng 12 năm 2020

Thời gian ngừng hoạt động: Khoảng sáu giờ

Vấn đề gốc rễ: Lỗi lan truyền khối

Sửa lỗi:

• Theo dõi các khối bằng hash thay vì số khe
• Sửa chữa các vị trí trong Tuabin nơi có thể phát hiện lỗi sớm hơn
• Truyền bá lỗi được phát hiện đầu tiên cho tất cả các trình xác thực thông qua tin đồn

Sự cố này đã được gây ra bởi một vấn đề sửa chữa khối trước đây và xử lý mãkích hoạt bởi một lỗi không xác định trongTuabin, cơ chế lan truyền khối của SolanaSự cố xảy ra khi một validator truyền hai khối khác nhau cho cùng một khe và lan truyền chúng đến hai phân vùng riêng biệt (A và B) trong khi một phân vùng thứ ba phát hiện ra sự không nhất quán một cách độc lập.

Vì mỗi phân vùng chỉ nắm giữ một cổ đông ít người, không ai có thể đạt được sự đồng thuận của đa số siêu lớn để tiến triển chuỗi. Vấn đề cơ bản bắt nguồn từ cách cấu trúc dữ liệu nội bộ của Solana theo dõi các khối và trạng thái tính toán của chúng. Hệ thống sử dụng số khe Thời gian chứng minh (PoH) (một trình định danh u64) để tham chiếu đến trạng thái và khối tại khe đó. Khi mạng chia thành các phân vùng, các nút hiểu lầm các khối A và B như nhau, ngăn chặn sửa chữa đúng và đồng bộ hóa khối.

Mỗi phân vùng cho rằng phần vùng khác có cùng một khối, dẫn đến một mâu thuẫn cơ bản:

• Các nút giữ block A đã từ chối các nhánh phân nhánh từ block B
• Các nút giữ block B đã từ chối các nhánh phát sinh từ block A

Vì quá trình chuyển đổi trạng thái khác nhau giữa các phân vùng, trình xác thực không thể sửa chữa hoặc điều hòa các fork, ngăn chặn tính cuối cùng.

Biện pháp khắc phục cho vấn đề này là đểcho phép dịch vụ theo dõi các khối bằng mã hash thay vì số kheNếu bất kỳ số lượng block nào cho cùng một slot tạo ra các phân vùng, chúng sẽ được xử lý không khác biệt so với các phân vùng với các block chiếm slot khác nhau. Các node sẽ có khả năng sửa chữa tất cả các chi nhánh có thể, và sự đồng thuận sẽ có khả năng giải quyết các phân vùng.

Mặc dù lỗi là nguyên nhân ban đầu của sự cố, phần lớn thời gian ngừng hoạt động là kết quả của việc đợi đến khi đủ trọng lượng cổ phần trở lại trực tuyến, vì Solana yêu cầu ít nhất 80% cổ phần tham gia để tiếp tục sản xuất khối.

IDO Grape Protocol: Tháng 9 năm 2021

Thời gian chờ: Mười bảy giờ

Vấn đề gốc: Tràn bộ nhớ do giao dịch bot

Sửa chữa:

• Bỏ qua khóa ghi trên chương trình
• Giới hạn tỷ lệ trên việc chuyển tiếp giao dịch
• Hành vi thử lại RPC có thể cấu hình
• Ưu tiên giao dịch bỏ phiếu TPU

Vào ngày 14 tháng 9 năm 2021, Solana đã trải qua một sự cố lớn trên mạng sau khi Grape Protocol ra mắt cuộc cung cấp DEX ban đầu trên chuỗi (IDO) trên nền tảng gọi vốn Raydium AcceleRaytor. Chỉ trong vòng 12 phút kể từ khi IDO bắt đầu, mạng bị quá tải bởi một luồng giao dịch do bot tạo ra và ngừng sản xuất các khung thời gian cố định. Những bot này hiệu quả thực hiện một cuộc tấn công phân tán từ chối dịch vụ (DDoS), đẩy tải giao dịch vượt quá khả năng của mạng.

Tại đỉnh điểm tắc nghẽn:

• Một số máy chủ xác nhận đã nhận được hơn 300,000 giao dịch mỗi giây.
• Dữ liệu giao dịch thô vượt quá 1 Gbps, với 120.000 gói mỗi giây.
• Lưu lượng truy cập đôi khi vượt quá giới hạn vật lý của giao diện mạng, gây mất gói tại cổng chuyển mạch trước khi đến trình xác thực.

Số khe Solana mỗi giây trong thời gian gián đoạn Grape IDO vào ngày 14 tháng 9 năm 2021(Nguồn dữ liệu: Jump Crypto)

Một trong những bot đã cấu trúc các giao dịch của mình để ghi khóa 18 tài khoản chính, bao gồm chương trình mã thông báo SPL toàn cầu và chương trình Serum DEX hiện không còn tồn tại. Điều này đã chặn tất cả các giao dịch tương tác với các tài khoản này, làm giảm nghiêm trọng khả năng xử lý song song của Solana. Thay vì thực hiện các giao dịch một cách độc lập, mạng trở nên tắc nghẽn, xử lý các giao dịch tuần tự — làm trầm trọng thêm tình trạng tắc nghẽn.

Một bản vá mà bỏ qua khóa ghi trên các chương trình đã được phát triển và lên lịch phát hành. Sau đó, việc khởi động lại mạng đã kích hoạ nâng cấp này, vĩnh viễn loại bỏ điểm tấn công này.

Trong sự kiện IDO, các máy chủ nhận được một lượng giao dịch do bot tấn công và sau đó chuyển tiếp các giao dịch dư thừa cho người dẫn đầu tiếp theo, tăng cường tình trạng tắc nghẽn. Khởi động lại mạng đã giới hạn tỷ lệ chuyển tiếp giao dịch để ngăn chặn các cơn bão giao dịch tương lai từ việc làm cho các nhà lãnh đạo bị quá tải.

Các nút RPC của Solana tự động thử lại các giao dịch thất bại, một tính năng được thiết kế để cải thiện độ tin cậy. Tuy nhiên, cơ chế thử lại này đã làm trầm trọng thêm tình trạng ngập lụt giao dịch dưới tình trạng tắc nghẽn cực độ, giữ cho các giao dịch cũ được lưu hành thay vì cho phép mạng phục hồi. Solana 1.8 đã giới thiệu hành vi thử lại RPC có thể định cấu hình, cho phép các ứng dụng tối ưu hóa các lần thử lại với thời gian hết hạn ngắn hơn và các chiến lược lùi theo cấp số nhân.

Dưới tình trạng tắc nghẽn nghiêm trọng, lãnh đạo Solana đã không bao gồm giao dịch bỏ phiếu, mà rất quan trọng để duy trì sự nhất quán. Kết quả là, việc thiếu bỏ phiếu được xác nhận dẫn đến sự đình trệ trong sự nhất quán, làm ngừng sản xuất các khối gốc mới. Các phiên bản sau của khách hàng Solana đã giới thiệu một cơ chế để ưu tiên các giao dịch bỏ phiếu, ngăn chúng bị chôn vùi bởi các giao dịch thông thường trong các sự kiện tương lai.

Lỗi thứ hai: Integer Overflow

Trong quá trình khởi động lại mạng, một vấn đề thứ hai xuất hiện. Người xác thực đã báo cáo số tiền đặt cược đang hoạt động biến động mạnh. Vấn đề này bắt nguồn từ một lỗi trong đó tỷ lệ phần trăm cổ phần được nhân không chính xác với 100, vượt quá giá trị tối đa có thể. Cơ chế lạm phát đã tạo ra rất nhiều mã thông báo SOL mới đến nỗi nó tràn ra một số nguyên không dấu 64 bit. Lỗi này nhanh chóng được xác định và vá trước khi khởi động lại lần thứ hai.

Tắc nghẽn cao: Tháng 1 năm 2022

Thời gian chết: Không có

Nguyên nhân gốc rễ: Giao dịch trùng lặp quá mức

Sửa phần một phần:

• Các bản phát hành Solana 1.8.12 và 1.8.14
• Tối ưu hóa SigVerify chống trùng lặp
• Cải thiện hiệu suất bộ nhớ cache của bộ thực thi

Từ ngày 6 tháng 1 đến ngày 12 tháng 1 năm 2022, mạng chính Solana đã trải qua tình trạng tắc nghẽn mạng nghiêm trọng, dẫn đến hiệu suất bị suy giảm và ngừng hoạt động một phần. Sự gián đoạn được thúc đẩy bởi các bot spam các giao dịch trùng lặp quá mức, làm giảm đáng kể dung lượng mạng. Các khối mất nhiều thời gian hơn dự kiến để xử lý, khiến đơn vị chỉ huy tiếp theo phải phân nhánh và giảm thêm thông lượng. Vào lúc cao điểm, tỷ lệ giao dịch thành công giảm tới 70%. Khách hàng đã phải vật lộn để xử lý các giao dịch ngày càng phức tạp, tính toán cao của mạng, bộc lộ những hạn chế trong khả năng đáp ứng nhu cầu.

Tình trạng bất ổn bổ sung xảy ra từ ngày 21 đến 23/1, tình trạng ùn tắc kéo dài. Ngày 22/1, điểm cuối RPC công khai (https://api.mainnet-beta.solana.com) đã ngừng hoạt động do bị lạm dụng, vì cuộc gọi RPC hàng loạt bị spam đã làm quá tải hệ thống.

Để giải quyết những vấn đề này, Solana 1.8.12 phát hành đặc biệt nhắm mục tiêu chương trình kiệt sức bộ nhớ cache, trong khi Phiên bản 1.8.14 giới thiệu cải tiến cho bộ nhớ cache Sysvar, loại bỏ SigVerify, và loại bỏ trùng lặp SigVerify.

Candy Machine Spam: Tháng 4 / Tháng 5 năm 2022

Thời gian ngừng hoạt động: Tám giờ

Vấn đề gốc: Spam giao dịch từ tài khoản bot

Sửa lỗi:

• Thuế bot trên chương trình máy kẹo
• Cải tiến bộ nhớ trong Solana v1.10

Vào ngày 30 tháng 4 năm 2022, Solana đã trải qua một sự tăng đột ngột chưa từng có trong số lượng yêu cầu giao dịch. Một số nút báo cáo đã đạt tới sáu triệu yêu cầu mỗi giây, tạo ra hơn 100 Gbps lưu lượng mạng trên mỗi nút. Sự tăng đột ngột này được thúc đẩy bởi các bot cố gắng bảo đảm NFT mới thông qua chương trình Máy Kẹo Metaplex. Cơ chế đúc này hoạt động dựa trên nguyên tắc đến trước được phục vụ trước, tạo ra động lực kinh tế mạnh mẽ để lạm dụng mạng với các giao dịch và chiến thắng trong quá trình đúc.

Ngày 30 tháng 4 / 1 tháng 5, 2022 Lỗi máy bán kẹo, gói dữ liệu mỗi giây đầu vào (Nguồn dữ liệu: Jump Crypto)

Khi khối lượng giao dịch tăng vọt, các validator đã hết bộ nhớ và bị sập, cuối cùng dẫn đến sự trì hoãn của sự đồng thuận. Khả năng xử lý bỏ phiếu không đủ đã ngăn chặn việc hoàn thành các khối trước, ngăn chặn việc dọn dẹp các nhánh bị bỏ rơi. Kết quả là, các validator đã bị áp đảo bởi số lượng nhánh hơn họ phải đánh giá, vượt quá khả năng của họ ngay cả sau khi khởi động lại và cần phải can thiệp bằng tay để khôi phục lại mạng lưới.

Mặc dù sự cố này có nhiều điểm tương đồng với sự cố vào tháng 9 năm 2021, Solana đã thể hiện sự kháng cự cải thiện. Mặc dù trải qua 10.000% yêu cầu giao dịch hơn so với sự cố trước đó, mạng vẫn hoạt động được lâu hơn nhiều, phản ánh sự cải thiện của cộng đồng validator đối với các thách thức về quy mô trước đó.

Ngày 30 tháng 4 / 1 tháng 5 năm 2022, Lỗi máy bán kẹo, các nhà xác thực hoạt động(Nguồn dữ liệu: Jump Crypto)

Quá trình khởi động lại mạng diễn ra nhanh chóng trong thời gian ít hơn 1,5 giờ sau khi đã thống nhất về bản snapshot cơ bản. Solana v1.10 bao gồm cải tiến về việc sử dụng bộ nhớ nhằm kéo dài thời gian mà các nút có thể chịu đựng sự chậm trễ hoặc đình trệ.

Tuy nhiên, các vấn đề cơ bản vẫn chưa được giải quyết. Người lãnh đạo vẫn xử lý các giao dịch tranh giành dữ liệu tài khoản giống nhau theo cơ sở đến trước là được, mà không có biện pháp ngăn chặn spam hiệu quả, khiến người dùng không thể ưu tiên mức độ cấp bách của giao dịch của họ. Để giải quyết vấn đề này, ba cơ chế dài hạn đã được đề xuất là các giải pháp thực tế.

Việc áp dụng QUIC: Trước đây, Solana phụ thuộc vào giao thức mạng UDP (User Datagram Protocol) để gửi giao dịch thông qua Gulf Stream từ các nút RPC đến người dẫn hiện tại. Mặc dù nhanh và hiệu quả, UDP không có kết nối, thiếu kiểm soát luồng và xác nhận nhận. Do đó, không có cách có ý nghĩa nào để ngăn chặn hoặc giảm nhẹ hành vi lạm dụng. Để kiểm soát lưu lượng mạng, giao thức tiếp nhận giao dịch của máy chủ xác thực (tức là Giai đoạn Thu thập của TPU) đã được triển khai lại bằng QUIC.

QUIC cố gắng cung cấp sự kết hợp tốt nhất giữa TCP và UDP. Nó tạo điều kiện cho việc giao tiếp không đồng bộ nhanh chóng tương tự như UDP nhưng với các phiên an toàn và chiến lược kiểm soát luồng tiên tiến của TCP. Điều này cho phép giới hạn được đặt cho các nguồn lưu lượng cá nhân để mạng có thể tập trung xử lý các giao dịch chân thực. QUIC cũng có khái niệm về các luồng riêng biệt, vì vậy nếu một giao dịch bị mất, nó không chặn các giao dịch còn lại. Cuối cùng, QUIC đã được tích hợp vào khách hàng của Solana Labs với bản phát hành 1.13.4.

Stake-Weighted Chất Lượng Dịch Vụ (SWQoS)Một hệ thống mới ưu tiên lưu lượng mạng dựa trên cổ phần mà các validator nắm giữ đã được giới thiệu, đảm bảo rằng những người có cổ phần cao hơn có thể gửi giao dịch một cách hiệu quả hơn. Dưới cơ chế này, một validator với 3% tổng cổ phần có thể gửi lên đến 3% gói tin tổng cộng tới người dẫn đầu. SWQoS hoạt động như một biện pháp chống Sybil, làm cho việc tấn công mạng với giao dịch chất lượng thấp trở nên khó khăn hơn đối với những kẻ xấu. Tiếp cận này thay thế mô hình đến trước, đến trước, phục vụ trước, mà chấp nhận giao dịch một cách không phân biệt mà không xem xét nguồn gốc của chúng.

Giới thiệu về Phí Ưu tiên:Khi các giao dịch được tiếp nhận, chúng vẫn cạnh tranh để truy cập dữ liệu tài khoản chia sẻ. Trước đây, sự cạnh tranh này đã được giải quyết theo cơ bản dựa trên nguyên tắc đến trước thì được phục vụ trước, không cung cấp cách nào cho người dùng để biểu hiện sự cấp bách của giao dịch của họ. Vì bất kỳ ai cũng có thể gửi giao dịch, việc cân bằng cổ phần không phù hợp để ưu tiên ở giai đoạn này. Để giải quyết vấn đề này, một hướng dẫn mới đã được thêm vào chương trình Ngân sách tính toán, cho phép người dùng chỉ định một khoản phí bổ sung được thu khi thực thi và bao gồm vào khối. Tỷ lệ phí-đến-đơn vị tính toán xác định ưu tiên thực thi của một giao dịch, đảm bảo một cách tiếp cận động và dựa trên thị trường hơn đối với việc sắp xếp giao dịch.

Candy Machine Bot Tax

Metaplex nhanh chóng giới thiệu một loại thuế bot được cài đặt cứng là 0.01 SOL đối với giao dịch mint tương tác với chương trình Candy Machine để chống lại thư rác do bot điều khiển. Cơ chế chống thư rác này áp đặt một khoản phí tối thiểu để ngăn chặn hoạt động độc hại mà không phạt những người dùng hợp pháp mắc lỗi vô tình. Thuế được áp dụng trong các tình huống cụ thể, bao gồm:

• Cố gắng phát hành khi Máy Kẹo không hoạt động
• Cố gắng tạo ra khi không còn mục nào
• Giao dịch nơi việc đúc hoặc thiết lập bộ sưu tập không phải là chỉ thị cuối cùng
• Sử dụng ID bộ sưu tập không chính xác
• Hướng dẫn Bộ sưu tập Bộ sưu tập không khớp
• Một sự không phù hợp giữa người ký và người thanh toán giữa bộ sưu tập và hướng dẫn phát hành
• Giao dịch đáng ngờ liên quan đến các chương trình bị cấm
• Cố gắng tạo ra từ Máy bánh kẹo được bảo vệ bởi Danh sách cho phép mà không giữ token danh sách cho phép cần thiết

Biện pháp ngăn chặn kinh tế này đã rất hiệu quả. Các thợ đúc nhanh chóng bị cạn kiệt và hoạt động spam ngừng lại. Trong những ngày đầu tiên, các botters đã mất hơn 426 SOL.

Lỗi Nonce bền bỉ: Tháng 6 năm 2022

Thời gian chết: Bốn tiếng rưỡi

Vấn đề gốc: Lỗi nonce bền vững dẫn đến sự cố đồng thuận

Sửa chữa:

• Tạm thời vô hiệu hóa giao dịch nonce bền vững
• Cập nhật Solana 1.10.23

Một lỗi thời gian chạy cho phép một số giao dịch durable nonce cụ thể được xử lý hai lần — một lần như một giao dịch thông thường và một lần nữa như một giao dịch nonce — nếu chúng sử dụng một blockhash gần đây thay vì một durable nonce trong trường recent_blockhash. Điều này dẫn đến hành vi không xác định giữa các validator, vì một số node từ chối thực thi thứ hai trong khi các node khác chấp nhận nó. Quan trọng, vì hơn một phần ba validator chấp nhận block, điều này ngăn không để đạt được sự đồng thuận của hai phần ba cần thiết.

Không giống như các giao dịch tiêu chuẩn, các giao dịch nonce bền vững không hết hạn và yêu cầu một cơ chế duy nhất để ngăn chặn việc thực hiện kép. Chúng được xử lý tuần tự bằng cách sử dụng giá trị nonce trên chuỗi được gắn với mỗi tài khoản, được xoay vòng mỗi khi giao dịch nonce bền vững được xử lý. Sau khi luân chuyển, cùng một giao dịch nonce sẽ không hợp lệ trở lại.

Để giảm thiểu vấn đề, các giao dịch nonce bền vững đã tạm thời bị vô hiệu hóa.Một sửa lỗi đã được triển khai sau đó trong Solana 1.10.23đã ngăn chặn việc thực thi trùng lặp bằng cách phân tách miền nonce và miền blockhash. Bản cập nhật đã đảm bảo rằng khi tiến hành các tài khoản nonce, blockhash được băm với một chuỗi cố định, làm cho một blockhash trở nên không hợp lệ như một giá trị nonce. Kết quả là, một giao dịch thực thi một lần như một giao dịch thông thường không thể được thực thi lại như một giao dịch bền vững, và ngược lại. Ngoài ra, một loại DurableNonce mới đã thay thế các giá trị blockhash trước đó trong trạng thái tài khoản nonce, thêm tính an toàn loại và ngăn chặn các vấn đề tương tự trong tương lai.

Đọc bài viết blog Helius trước đó của chúng tôi để hiểu thêm về số thứ tự bền vững và cách sử dụng của chúng.

Lỗi Khối Trùng Lặp: Tháng 9 Năm 2022

Thời gian chờ: Tám giờ và nửa

Vấn đề gốc: Một lỗi trong quy tắc lựa chọn fork dẫn đến sự cố về đồng thuận

Sửa chữa:

• Bản vá khách hàng

Sự cố này được kích hoạt bởi một validator sai lầm sản xuất các khối trùng lặp ở cùng một chiều cao khối. Điều này xảy ra vì cả nút chính của validator và nút dự phòng dư thừa của nó trở nên hoạt động đồng thời, sử dụng cùng một danh tính nút nhưng đề xuất các khối khác nhau. Tình trạng này duy trì ít nhất 24 giờ trước khi xảy ra sự cố, trong thời gian đó mạng đã xử lý chính xác các khe hạng lãnh đạo trùng lặp của validator.

Cluster cuối cùng đã dừng lại khi mạng gặp phải một đường fork không thể khôi phục do lỗi trong logic lựa chọn fork. Lỗi này đã ngăn chặn các nhà sản xuất block từ việc xây dựng trên block trước đó, dẫn đến sự thất bại trong sự đồng thuận.

Fork là một sự xuất hiện thường xuyên trên Solana và các trình xác thực thường giải quyết chúng bằng cách căn chỉnh trên fork với đa số phiếu bầu (fork nặng nhất). Khi trình xác thực chọn sai fork, nó phải chuyển sang fork nặng nhất để luôn đồng bộ với mạng. Tuy nhiên, trong trường hợp này, người xác thực không thể hoàn nguyên về ngân hàng nặng nhất nếu vị trí của nó khớp với vị trí được bình chọn cuối cùng của họ. Lỗ hổng này khiến các trình xác thực vẫn bị mắc kẹt, ngăn cản sự đồng thuận tiến triển và cuối cùng dẫn đến việc tạm dừng mạng.

Sự cố lỗi khối trùng, lựa chọn fork, tháng Chín năm 2022(Nguồn: Laine, Michael Hubbard)

Trong ví dụ trên, validator lỗi C tạo ra các khối trùng lặp cho các khe của người dẫn đầu từ 5 đến 8. Khi validator G tiếp quản vị trí người dẫn đầu tiếp theo, nó chỉ quan sát một trong những bản sao và mở rộng nhánh của mình tương ứng. Tuy nhiên, người dẫn đầu tiếp theo, validator D, phát hiện ra cả hai khối trùng lặp từ validator C và quyết định loại bỏ chúng, thay vì xây dựng nhánh của mình trên khe 4.

Khi mạng tiến triển, nhánh được xây dựng bởi validator G giành được phiếu bầu từ đa số cổ phần, xác định bản thân là chuỗi chính thức. Nhận thấy nhánh của mình đang thua, validator D cố gắng chuyển sang nhánh của validator G. Tuy nhiên, quá trình chuyển đổi thất bại do lỗi trong logic chọn nhánh. Vấn đề này phát sinh vì tổ tiên chung của hai nhánh - một khối trùng lặp tại slot 5 - không được xử lý đúng cách, ngăn validator D nhận ra nhánh đa số. Kết quả là, validator D vẫn bị kẹt trên nhánh của mình, không thể quay trở lại chuỗi chính.

Vấn đề đã được giải quyết sau khi nhóm nòng cốt xem xét. Một bản vá đã được sáp nhập vào nhánh chính và được hỗ trợ cho tất cả các nhánh phát hành.

Khối Lớn Quá Tải Cánh Quạt: Tháng 2 Năm 2023

Thời gian chết: Gần 19 giờ

Vấn đề gốc: Sự cố của logic deduplication trong các dịch vụ chuyển tiếp shred

Sửa chữa:

• Nhiều cải tiến cho logic loại bỏ trùng lặp và lọc của Turbine
• Thêm bản vá khách hàng buộc các nhà sản xuất khối phải hủy nếu họ tạo ra các khối lớn

Dịch vụ chuyển tiếp shred tùy chỉnh của một validator đã gặp sự cố, truyền một khối lớn đặc biệt (gần 150.000 shred), nhiều lần lớn hơn một khối chuẩn, trong khe sóng lãnh đạo của mình. Điều này làm cho bộ lọc trùng lặp của validator bị quá tải, gây ra dữ liệu bị chuyển tiếp liên tục. Vấn đề trở nên nghiêm trọng khi các khối mới được tạo ra, cuối cùng làm bão hòa giao thức.

Mất khối lớn, băm nhỏ mỗi khối, Tháng Hai 2023 (Nguồn: Laine, Michael Hubbard)

Sự tăng đột ngột trong lưu lượng mạng bất thường đã làm cho Turbine bị quá tải, buộc dữ liệu khối phải được truyền qua giao thức Block Repair dự phòng chậm hơn đáng kể. Mặc dù Turbine được thiết kế để chịu được các khối lớn bằng cách lọc chúng ra, dịch vụ chuyển tiếp shred hoạt động ở phía trước của logic lọc này, làm giảm hiệu quả của nó. Trong thời kỳ suy giảm, các nhà lãnh đạo khối tự động chuyển sang chế độ chỉ bỏ phiếu, một cơ chế an toàn mà trong đó các nhà lãnh đạo loại trừ các giao dịch phi bỏ phiếu kinh tế.

Nguyên nhân gốc rễ của vấn đề là sự thất bại trong logic chống trùng lặp trong các dịch vụ chuyển tiếp băm nhỏ, ngăn chặn việc truyền lại dư thừa các mảnh vụn. Ngoài ra, bộ lọc chống trùng lặp trong đường ống truyền lại ban đầu không được thiết kế để ngăn chặn vòng lặp trong cây Tuabin, làm trầm trọng thêm vấn đề.

Mạng đã được khởi động lại thủ công với việc hạ cấp xuống phiên bản phần mềm xác nhận cuối cùng ổn định đã biết. Để giảm thiểu những vấn đề này, Solana v1.13.7 và v1.14.17 đã giới thiệu các cải tiến cho logic chống trùng lặp, cải thiện khả năng ngăn chặn độ bão hòa bộ lọc và đảm bảo hiệu suất mạng mạnh mẽ hơn.

Infinite Recompile Loop: Tháng Hai 2024

Thời gian ngừng hoạt động: Gần năm giờ

Vấn đề gốc: Lỗi gây ra vòng lặp biên dịch lại vô hạn trong bộ đệm JIT

Sửa chữa:

• Vô hiệu hóa trình tải cũ v1.17.20

Trình xác thực Agave just-in-time (JIT) biên dịch tất cả các chương trình trước khi thực hiện các giao dịch tham chiếu đến chúng. Để tối ưu hóa hiệu suất, đầu ra JIT của các chương trình được sử dụng thường xuyên được lưu vào bộ nhớ cache, giảm việc biên dịch lại không cần thiết. Là một phần của Agave v1.16, cơ chế bộ nhớ đệm hiện có, LoadedPrograms, đã được thay thế bằng một triển khai mới gọi là ExecutorsCache, giới thiệu một số hiệu quả.

LoadedPrograms cung cấp chế độ xem toàn cầu, nhận biết ngã ba của các chương trình được lưu trong bộ nhớ cache, giảm trùng lặp dữ liệu kế toán và cho phép các luồng thực hiện giao dịch tải các chương trình mới một cách hợp tác, ngăn ngừa xung đột biên dịch. Một tính năng chính của hệ thống này là theo dõi khe cắm nơi chương trình hoạt động (được gọi là chiều cao khe hiệu quả) để phát hiện vô hiệu hóa bộ nhớ cache khi dữ liệu chương trình trên chuỗi được cập nhật.

Chiều cao khe hiệu quả của hầu hết các chương trình được suy ra từ khe triển khai của chúng, được lưu trữ trong tài khoản trên chuỗi của họ. Tuy nhiên, các chương trình triển khai bằng các trình tải cũ không giữ lại khe triển khai này trong tài khoản của họ. LoadedPrograms gán cho những chương trình này một chiều cao khe hiệu quả là không để tạm thời khắc phục vấn đề.

Một ngoại lệ đã xảy ra khi phát hiện một lệnh triển khai, cho biết bytecode của một chương trình đã được thay thế. Trong trường hợp này, LoadedPrograms tạm thời chèn một mục với chiều cao khe hiệu quả đúng. Tuy nhiên, do giao dịch không bao giờ tham chiếu đến mục này, nó rất dễ bị loại bỏ. Khi bị loại bỏ, đầu ra JIT được loại bỏ và chương trình được đánh dấu là đã bị tải, nhưng chiều cao khe hiệu quả được giữ nguyên.

Nếu một giao dịch sau đó tham chiếu đến chương trình không tải này, LoadedPrograms đã biên dịch lại nó và chèn lại một mục nhập ở độ cao khe hiệu quả của nó. Thông thường, điều này sẽ làm cho chương trình có sẵn để thực thi trong lần lặp tiếp theo. Tuy nhiên, đối với các chương trình tải cũ, đầu ra JIT mới được gán chiều cao khe cắm trọng điểm bằng không, đặt nó phía sau mục nhập không tải trước đó. Kết quả là, LoadedPrograms không bao giờ nhận ra chương trình là đã tải, kích hoạt vòng lặp biên dịch lại liên tục trên mỗi lần lặp.

Trong Agave v1.16, LoadedPrograms không hỗ trợ tải hợp tác, cho phép giao dịch kích hoạt được đóng gói vào một khối. Khối này sau đó được lan truyền trên mạng, làm cho mọi người kiểm tra lại và nhập cùng vào vòng lặp biên dịch vô hạn. Vì hơn 95% cổ phần cụm đang chạy Agave v1.17 trong thời gian gián đoạn, hầu hết các máy chủ xác thực trở nên tê liệt trên khối này, làm đứng mạng.

Lỗi này đã được xác định vào tuần trước trong một cuộc điều tra về sự cố ngừng hoạt động của cụm Devnet và một bản vá đã được lên kế hoạch triển khai. @jeff.washington/2024-02-06-solana-mainnet-beta-outage-report-619bd75b3ce0”>Biện pháp giảm nhẹ được lựa chọn là backport các thay đổi vào Agave v1.17 và ngay lập tức loại bỏ một cổng tính năng sau khi mạng được khởi động lại. Điều này vô hiệu hóa trình tải kế thừa chịu trách nhiệm kích hoạt lỗi, ngăn chặn sự cố tiếp theo.

Bản vá lỗ hổng phối hợp: Tháng Tám 2024

Thời gian chết: Không có

Vấn đề gốc: Giả định căn chỉnh địa chỉ ELF không chính xác

Sửa lỗi:

• Bản vá cập nhật

Vào ngày 5 tháng 8, Các kỹ sư cốt lõi của Anza đã được cảnh báo về một lỗ hổng trong client Agave, được báo cáo bởi một nhà nghiên cứu bên ngoài. Kẻ tấn công có thể đã khai thác lỗ hổng này để làm sập trình xác thực đơn vị chỉ huy, dẫn đến việc tạm dừng trên toàn mạng. Đáp lại, các kỹ sư của Anza đã nhanh chóng phát triển một bản vá, mà nhiều công ty bảo mật bên thứ ba sau đó đã kiểm tra.

Các chương trình Solana được biên dịch bằng LLVM vào Định dạng thực thi và có thể liên kết (ELF). Lỗ hổng bảo mật xuất phát từ giả định căn chỉnh địa chỉ không chính xác trong các tệp ELF được tạo này. Mặc dù vệ sinh ELF thường thực thi các kiểm tra tính toàn vẹn khác nhau, nhưng nó không xác thực sự liên kết của phần .text. Sự giám sát này có thể đã cho phép một tệp ELF được tạo độc hại để xác định phần .text bị lệch, dẫn đến máy ảo chuyển đến một địa chỉ không hợp lệ. Điều này sẽ dẫn đến lỗi phân đoạn máy chủ, làm hỏng trình xác thực.

Kẻ tấn công có thể đã khai thác lỗ hổng này bằng cách:

• Tạo một chương trình Solana độc hại sử dụng opcode CALL_REG.
• Thao tác với tệp ELF để căn chỉnh sai phần .text.
• Triển khai và gọi chương trình trên mạng, gây ra sự cố trình xác thực.

Quá trình cập nhật bản vá

Bất kỳ bản cập nhật bản vá nào được phát hành công khai sẽ ngay lập tức làm cho lỗ hổng rõ ràng cho tất cả mọi người. Điều này có thể cho phép kẻ tấn công có đủ thời gian để đảo ngược kỹ thuật lỗ hổng và tạm dừng mạng trước khi một lượng cổ phần đủ được nâng cấp. Một khối lượng lớn trình xác thực quan trọng sẽ cần phải áp dụng bất kỳ bản phát hành bản vá nào càng nhanh càng tốt để tránh kịch bản như vậy.

Đến ngày 7/8, nhiều thành viên của Solana Foundation đã liên hệ với người xác thực thông qua tin nhắn riêng tư trên các nền tảng truyền thông khác nhau, thông báo với họ về một bản vá quan trọng sắp tới và chia sẻ một tin nhắn băm xác nhận ngày tháng và định danh duy nhất của sự cố. Nhiều thành viên nổi bật của Anza, Jito và Quỹ Solana đã chia sẻ băm này trên X, GitHub và LinkedIn để xác minh tính chính xác của tin nhắn. Ví dụ về băm được chia sẻ:

Trong ngày hôm sau, các thành viên cốt lõi tiếp tục liên hệ với người xác thực, nhấn mạnh tầm quan trọng của tính cấp bách và bảo mật. Vào thời điểm được xác định trước, ngày 8 tháng 8, 2 giờ chiều UTC, các nhà khai thác trình xác thực đã nhận được thêm một thông báo chứa hướng dẫn tải xuống, xác minh và áp dụng bản vá. Bản vá được lưu trữ trên kho lưu trữ Github của một kỹ sư Anza nổi tiếng, không phải kho lưu trữ Agave chính. Hướng dẫn bao gồm xác minh các tệp bản vá đã tải xuống so với shasums được cung cấp.

Đến 8 giờ tối UTC ngày 8/8, phần lớn cổ phần đã được vá lỗi, đảm bảo an ninh mạng. Sau đó, lỗ hổng và bản vá tương ứng của nó đã được tiết lộ công khai, kèm theo lời kêu gọi tất cả các trình xác thực còn lại nâng cấp.

Sự phân phối lặng lẽ của bản vá và sự phối hợp hậu trường của các trình xác thực đã làm dấy lên lo ngại về sự phân cấp của Solana. Ngay sau vụ việc, giám đốc điều hành của Solana Foundation, Dan Albert, đã giải quyết những lời chỉ trích này trong một cuộc phỏng vấn truyền thông.

“Tôi nghĩ điều quan trọng là không nhầm lẫn giữa tập trung hóa với khả năng phối hợp. Có 1.500 nút sản xuất khối trên toàn thế giới được vận hành bởi gần như nhiều cá nhân…. Khả năng giao tiếp với họ, hoặc một số người trong số họ, một cách tự nguyện, không nên nhầm lẫn với tập trung.

Tuần lễ Blockchain Hàn Quốc (KBW) 2024

Tôi nghĩ điều quan trọng là không nhầm lẫn giữa tập trung hóa với khả năng phối hợp. Có 1.500 nút sản xuất khối trên toàn thế giới được vận hành bởi gần như nhiều cá nhân…. Khả năng giao tiếp với họ, hoặc một số trong số họ, một cách tự nguyện, không nên nhầm lẫn với tập trung.

Kết luận

Kể từ thời điểm viết bài này, Solana đã trải qua hơn một năm mà không có sự cố, đạt một mốc quan trọng để loại bỏ nhãn “beta” khỏi mainnet-beta. Tần suất sự cố dường như đang giảm đi khi mạng lưới trở nên trưởng thành, và việc giới thiệu Firedancer được kỳ vọng sẽ tăng cường sự đa dạng của khách hàng, giảm thiểu rủi ro từ những lỗi chưa được phát hiện hoặc các trường hợp cạnh nhau gây ra sự cố toàn cụm. Tuy nhiên, một số lãnh đạo cộng đồng, bao gồm cả người sáng lập Helius Mert Mumtaz, đã dự đoán rằng các sự cố sẽ tiếp tục diễn ra. Thời gian sẽ cho biết.

Rất cảm ơn Zantetsu (Hệ thống Shinobi) và OxIchigo đã xem xét các phiên bản trước của công việc này.

Disclaimer:

1. Bài viết này được in lại từ [Helius]. Tất cả bản quyền thuộc về tác giả gốc [Lạc lối]. Nếu có ý kiến phản đối bản in lại này, vui lòng liên hệ với Cổng họcđội ngũ và họ sẽ xử lý ngay lập tức.
2. Từ chối trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không hề cấu thành bất kỳ lời khuyên đầu tư nào.
3. Nhóm Gate Learn thực hiện dịch bài viết sang các ngôn ngữ khác. Sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm trừ khi được đề cập.