BTC
ETH
HTX
SOL
BNB
Xem thị trường
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

Vụ nổ và phá hủy quả bom độ khó Ethereum

以太坊爱好者
特邀专栏作者
Bài viết này có khoảng 5284 từ, đọc toàn bộ bài viết mất khoảng 8 phút
Làm thế nào mà quả bom phát nổ,? Tư thế gỡ bom đúng là gì?
Tóm tắt AI
Làm thế nào mà quả bom phát nổ,? Tư thế gỡ bom đúng là gì?

Lưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ethfans)Lưu ý của biên tập viên: Bài viết này đến từ

Những người đam mê Ethereum (ID: ethfans)

Những người đam mê Ethereum (ID: ethfans)

, Tác giả: Thomas Jay Rush, bản dịch & hiệu đính: Zeng Mi & A Jian, được Odaily tái bản với sự ủy quyền.

Bất cứ khi nào quả bom hẹn giờ của Ethereum phát nổ, luôn có hai vấn đề xuất hiện trước mắt chúng ta. Câu hỏi đầu tiên (và có thể nói là quan trọng hơn) là: "Khi nào việc sản xuất khối sẽ chậm lại, điều đó thật không thể chịu nổi." Câu hỏi thứ hai là, "Lần này, chúng ta nên trì hoãn quả bom trong bao lâu?"

Trong bài luận ngắn này, tôi đề xuất một câu trả lời đơn giản tầm thường cho câu hỏi thứ hai. Quả bom độ khó nên bị trì hoãn trong bao lâu? Đề xuất của tôi là: "Với một hard fork cần được thực hiện ở độ cao khối N, hãy trì hoãn quả bom độ khó bằng N khối (hoặc ít hơn để tăng cường bảo mật)."

Tôi sẽ không giải thích cách tính độ khó trong bài viết này (hãy xem bài viết trước của tôi nếu bạn muốn biết). Hình dưới đây đã xuất hiện trong bài viết trước của tôi, trong đó liệt kê công thức tính độ khó.

(Văn bản trong hình: Giá trị độ khó hiện tại dc có được bằng cách cộng giá trị độ khó trước đó dp và hai phần. Phần đầu điều chỉnh độ khó dựa trên khoảng thời gian giữa khối hiện tại và khối trước đó. Đặt s = tsc - ts, khi s < 10, hệ số max(x) trong công thức trên ước tính bằng 1 (giả sử phương pháp chia hết). Trong trường hợp này, việc tạo khối quá nhanh sẽ làm tăng độ khó và do đó làm chậm tốc độ tạo khối. Nếu 10<= s < 20 thì hệ số max(x) sẽ trở thành 0, như vậy đảm bảo khi s gần với thời gian mục tiêu là 14 giây thì độ khó sẽ không bị điều chỉnh nữa, còn nếu s>=20 thì giá trị của hệ số max(x) sẽ trở thành Hệ số giảm dần đến -99, điều này làm cho độ khó giảm xuống, do đó làm tăng tốc độ sản xuất khối. Phần thứ hai của phương trình dựa trên số khối của khối trước đó. chia 100.000 theo số mũ, 100.000 khối là một hàm bước định kỳ. Phần thứ hai là cái mà chúng ta thường gọi là quả bom độ khó. Không có phần thứ hai, quả bom độ khó là không thể nói đến.)

Phần đầu tiên của công thức, tôi gọi là "điều chỉnh" (hoặc Phần A). Phần này điều chỉnh độ lệch của thời gian tạo khối của khối trước đó bằng cách điều chỉnh độ khó của khối hiện tại. Sự điều chỉnh này làm giảm hoặc tăng độ khó, tùy thuộc vào khoảng thời gian cần thiết để tạo khối cuối cùng. Dấu ngoặc đầu tiên trong hình trên làm nổi bật phần này. Hãy dành một chút thời gian để tìm hiểu làm thế nào nó hoạt động. Hiệu quả thực tế của phần A hoàn toàn giống với mục tiêu thiết kế, chức năng của nó là làm dịu tác động của biến động tỷ lệ băm đối với hoạt động của mạng (Ghi chú của người dịch: Tỷ lệ băm là một đơn vị sức mạnh tính toán, vì vậy nó cũng được dùng để chỉ sức mạnh tính toán). Từ biểu đồ bên dưới, bạn có thể thấy rõ rằng phần A của công thức tính toán hoạt động chính xác như mong đợi.

Chỉ vì phần A hoạt động như được thiết kế để loại trừ ảnh hưởng của tỷ lệ băm, tôi không nghĩ cần phải xem xét quy mô thực tế của sức mạnh tính toán khi nghĩ về cách trì hoãn quả bom hẹn giờ. Nói cách khác, sức mạnh tính toán quá thấp sẽ không làm cho thời gian tạo khối lâu hơn khi quả bom độ khó phát nổ và sức mạnh tính toán quá cao sẽ không làm giảm tác dụng của quả bom độ khó. Với phân tích trên, kết luận của tôi là phần A của công thức không liên quan gì đến việc làm chậm thời gian tạo khối. Và phần thứ hai của công thức (phần B gây ra quả bom) chính là thủ phạm gây ra mọi rắc rối.

Phân tích sau đây sẽ thuyết phục bạn rằng hoàn toàn có thể xử lý hai phần này một cách riêng biệt. Những phân tích này giúp dễ dàng nhận thấy rằng phần A không ảnh hưởng đến việc tạo khối, trong khi phần B - quả bom - khiến thời gian tạo khối kéo dài. Bên cạnh đó, bạn sẽ biết việc gỡ bom dễ dàng như thế nào chỉ bằng cách đặt lại kỷ nguyên về 0 trên mỗi lần phân nhánh.

tiêu đề phụ

Tạo dữ liệu và định dạng

Chạy đoạn mã trên, bạn có thể tạo tệp dữ liệu rất đơn giản sau ở định dạng .csv...

Dữ liệu trên, kết hợp với danh sách tỷ lệ băm hàng ngày thu được từ EtherScan, là quá đủ để chúng ta hiểu được cách tính toán độ khó của Ethereum. Chúng tôi đã sử dụng RStudio và một ngôn ngữ lập trình dữ liệu có tên là "R" để tạo các biểu đồ bên dưới. Nếu bạn không quen thuộc với ngôn ngữ "R", bạn nên kiểm tra nó, đây là một ngôn ngữ lập trình rất tốt.

Trước tiên, hãy xem xét tỷ lệ băm của Ethereum.

Tỷ lệ băm trung bình hàng ngày

Biểu đồ đầu tiên hiển thị tỷ lệ băm trung bình hàng ngày của mạng chính Ethereum, với dữ liệu từ EtherScan. Vì tôi không biết dữ liệu được thu thập/tạo ra như thế nào nên tôi không thể đảm bảo tính xác thực của dữ liệu, nhưng tôi cho rằng dữ liệu đó chính xác. Bạn có thể nhấp vào liên kết này để xem dữ liệu liên quan.

Thảo luận: Từ biểu đồ trên, rõ ràng là hashrate của Ethereum thay đổi theo giá của Ether. Biểu đồ này làm tôi nhớ đến hành động giá của Ethereum. Vào mùa hè năm 2017, tỷ lệ băm tăng vọt và đạt đỉnh vào quý đầu tiên của năm 2018 (chính xác bằng giá tiền tệ). Sự biến động của hashrate vào tháng 10 năm 2016 là do cuộc tấn công DDos khét tiếng vào thời điểm đó.Hai đường thẳng đứng màu xám trong hình trên đại diện cho hai hard fork — hard fork Byzantine (tháng 10 năm 2017) và hard fork Constantinople (tháng 1 năm 2019) . Bức tranh này tạm thời được phân tích ở đây, nhưng chúng tôi vẫn sẽ đề cập đến nó khi thảo luận về dữ liệu độ khó của blockchain tiếp theo.

tiêu đề phụ

Dữ liệu độ khó thô

Biểu đồ đầu tiên dựa trên dữ liệu độ khó hiển thị dữ liệu được trả về bởi lệnh gọi RPC của Parity get_Block. Đầu tiên, một số thống kê tiêu chuẩn được liệt kê dưới đây:

Biểu đồ đầu tiên của chúng tôi khá trực quan:

Thảo luận: Dữ liệu trong hình trên được tạo tại khối 8.920.000. Mặc dù xử lý nhiều bản ghi dữ liệu này là một miếng bánh trong ngôn ngữ "R", do tính chất lặp lại của khai thác dữ liệu, chúng tôi đã lấy mẫu 1 trong số 100 bản ghi, dẫn đến khoảng 9.000 bản ghi và trình bày những điều trên trong hình. Phù hợp với bài viết trước, đường thẳng đứng màu xám trong hình trên cũng đại diện cho một hard fork.

Chiều cao của đường màu đỏ (y(x) = độ khó tại khối.x ) biểu thị giá trị độ khó tại khối đã cho. Bạn có thể dễ dàng nhận thấy tác dụng của việc phá bom độ khó ở mỗi ngã ba. Quay trở lại biểu đồ về hash rate trong bài viết trước, trong vụ tấn công DDos vào mùa thu năm 2016, bạn có thể thấy mối quan hệ giữa độ khó và hash rate.

Giả sử quả bom độ khó không bị phá hủy - thực sự kéo dài đường màu đỏ lên trên từ độ cao mà độ khó được kích hoạt - hãy làm tương tự cho cả hai nhánh cứng và bạn sẽ thấy rằng điều này phù hợp một cách đáng ngạc nhiên với biểu đồ thay đổi tỷ lệ băm . Nói cách khác, tỷ lệ băm và độ khó được liên kết chặt chẽ với nhau, điều này hoàn toàn hợp lý. Bởi vì đó là mục đích của phần A của công thức độ khó. Nó tồn tại để điều chỉnh trực tiếp giá trị độ khó cho các hàm băm khác nhau.

Hành vi của những người khai thác có thể không thay đổi do việc tháo dỡ quả bom độ khó. Các giàn khai thác của họ tiếp tục hoạt động tốt như nhau trước và sau khi quả bom độ khó không còn tồn tại. Thay đổi duy nhất là thời gian trung bình để tạo ra một khối đã trở nên ngắn hơn.

Thảo luận: Chúng tôi chia biểu đồ trên bằng các đường thẳng đứng trong các nhóm 100.000 khối. Hãy mở to mắt và nhìn kỹ, đường cong thể hiện độ khó nhảy trùng khớp hoàn toàn với đường thẳng đứng (đường phân chia) mà chúng ta đã tạo. Giữa những dải phân cách này, độ khó tiếp tục tăng lên, nhưng gần như không nhanh bằng khi nhảy lên dải phân cách. Sự gia tăng bùng nổ về độ khó phù hợp với thực tế là tỷ lệ băm tăng vọt trong năm 2017.

Có thể bạn cũng nhận thấy mỗi "vụ nổ" liên tiếp - mỗi lần quả bom phát nổ, giá trị độ khó tăng gấp đôi so với lần trước. Hóa ra tính chu kỳ của những bước nhảy này đặc biệt quan trọng để hiểu điều gì đang diễn ra trong thời điểm hiện tại.

Trong các sơ đồ cho phần còn lại của bài viết này, mục tiêu của chúng tôi là tách phần đầu tiên (tức là phần A hoặc "điều chỉnh") và phần thứ hai (tức là phần B hoặc "sự bùng nổ") của công thức độ khó. Do đó giúp chúng tôi hiểu rõ hơn về cách đối phó với những quả bom độ khó trong tương lai.

tiêu đề phụ

Độ khó thay đổi từng khối

Trong biểu đồ tiếp theo, chúng tôi xem xét sự thay đổi về độ khó giữa mỗi khối liên tiếp. Công thức tính của nó là y(x) = độ khó của khối x - độ khó của khối x-1

Đối với bạn, biểu đồ này có thể là biểu diễn trực quan đầu tiên của bạn về quả bom độ khó. Rõ ràng, mỗi vụ nổ khó gấp đôi lần trước.

Nhưng theo tôi, bức tranh này vẫn chưa đủ rõ ràng. Ví dụ, tại sao mô hình tương tự không xuất hiện lại rõ ràng trong Constantinople? Trên thực tế, đó là do tỷ lệ băm đã tăng lên rất nhiều. Phần tính toán này có thể duy trì thời gian khối ở mức 14 giây, nhưng hệ thống dao động dữ dội hơn. Điều này cũng giải thích tại sao chúng tôi không thể xác định được quả bom độ khó khi nó đến gần ngã ba Constantinople, vì nó bị lu mờ bởi những dao động dữ dội hơn.

Vì vậy, có một số biện pháp khác có thể cho phép chúng ta nhìn rõ hơn? chắc chắn! Phương pháp này tồn tại và chúng tôi sẽ tiết lộ nó cho bạn trong biểu đồ tiếp theo.

tiêu đề phụ

Thay đổi tương đối về độ khó

Biểu đồ cuối cùng trong phần này của bài viết cho thấy phần trăm thay đổi về độ khó so với tổng độ khó của khối. Công thức tính là

Biểu đồ trước cho thấy sự thay đổi thô về độ khó. Biểu đồ này cho thấy sự thay đổi độ khó được chuẩn hóa, loại bỏ ảnh hưởng của việc tăng tỷ lệ băm, để chúng ta có thể thấy rõ hơn hai phần khác nhau của công thức tính toán độ khó - phần A và phần B.

Thảo luận: Bây giờ chắc bạn đã hiểu tại sao tôi lại nói ở bài viết trước rằng khi bàn luận về bom độ khó thì việc lo lắng về sức mạnh tính toán sẽ phản tác dụng. Từ biểu đồ này, bạn có thể thấy rõ rằng việc sản xuất khối không bị ảnh hưởng bởi sự tăng (hoặc giảm) của hashrate cho đến khi quả bom hẹn giờ “ngẩng đầu lên”. Phần A của công thức giữ tốc độ và sản lượng sản xuất khối ở trạng thái ổn định. Độ khó (từ dữ liệu trung bình và chuẩn hóa) hầu như không bị ảnh hưởng nhiều cho đến khi quả bom hẹn giờ nổ.

Có hai điều thú vị hơn cần lưu ý ở đây: (1) Từ hình ảnh trên, bạn cũng có thể thấy rằng các quả bom bắt đầu "nhìn lên" ở phía ngoài cùng bên phải của biểu đồ, mặc dù xa hơn so với khoảng cách giữa Byzantium và Constantinople .(2) các vệt ở dưới cùng của biểu đồ là do một phần của công thức chia cho 10 trong phần A của công thức; ", như Lane Rettig đã đề cập trước ngã ba Constantinople, mà chúng tôi cũng đã viết trong bài báo được đề cập ở trên.

Tôi vẫn còn nhiều điều muốn chia sẻ về bức ảnh này, có thể một ngày nào đó tôi sẽ quay lại và viết tiếp. Nhưng sau đó, tôi muốn có một cách tốt hơn để gỡ bom trong tương lai.

tiêu đề phụ

Một cách tốt hơn để gỡ bom

Trước hết, tôi muốn nhấn mạnh lại rằng lo lắng về sự dao động của sức mạnh tính toán trong khi lo lắng về bom hẹn giờ là phản tác dụng. Phần A của công thức tính toán đã loại trừ tác động của việc tăng (hoặc giảm) sức mạnh tính toán. Đây chính xác là những gì Phần A nói về. Mức tăng độ khó gần như hoàn toàn bằng phẳng (so với chiều cao khối tại thời điểm đó) chứng tỏ rằng phần A hoạt động gần như hoàn hảo. Rõ ràng, tỷ lệ băm không ảnh hưởng đến thời gian tạo khối - nhưng chúng tôi đã biết điều này - đó là mục đích điều chỉnh độ khó.

Bom được xác định bởi một giá trị bổ sung được thêm vào cuối công thức trên:

(Ghi chú của người dịch: sàn(x) là một hàm làm tròn xuống, nghĩa là lấy số nguyên lớn nhất không lớn hơn x, ví dụ sàn(3.14) = 3)

Công thức trên là một hàm lũy thừa với cơ số 2. Đặt p = sàn(số khối hiện tại/100.000), chúng ta có thể viết lại công thức trên thành 2p. (Bạn có thể thắc mắc, liệu -2 ở cuối công thức có bị ăn mất không? Không, chúng ta tạm thời bỏ qua nó, vì chức năng của nó là làm cho giá trị được tính nhỏ hơn.) Cuối cùng, chúng ta có được một hàm bước dài.

Tuy nhiên, hãy nhớ rằng các nhà phát triển cốt lõi đã đặt lại quả bom hai lần - vâng, theo nghĩa đen là "đặt lại", họ đặt lại chu kỳ bắt đầu tính toán của quả bom. Điều này đạt được bằng cách sử dụng mã Go để tạo khối giả được sử dụng trong tính toán. Cho đến nay, các khối giả dường như đã có tác dụng đặt lại quả bom trong quá khứ. Biểu đồ đã hiệu chỉnh dưới đây cho thấy điều gì đã thực sự xảy ra trong giai đoạn này.

Bảng dưới đây liệt kê một số thông tin sau khi reset Bạn có thấy gì lạ không?

Số khối giả sau fork Byzantine là 1.370.000 và giá trị này được chia cho 100.000 để có chu kỳ 13. Nghĩa là, sau khi điều chỉnh tỷ lệ băm, độ khó của mỗi khối được tăng thêm 213. Khi hard fork Constantinople xảy ra, số khối giả được đặt lại thành 2.280.000, nghĩa là khoảng thời gian trở thành 22, nghĩa là độ khó của mỗi khối tăng thêm 222. Tôi nghĩ đó là lý do tại sao quả bom hẹn giờ phát nổ sớm hơn chúng tôi dự kiến. Bởi vì chúng tôi đã không quay lại đủ xa khi đặt lại lần cuối.

Giá trị được khuyến nghị để đặt lại quả bom hẹn giờ lần này là khôi phục 69.000 khối, làm cho kỷ nguyên bằng 0. Đây là số tiền chính xác để thiết lập lại.

Bất cứ khi nào chúng ta phải đặt lại quả bom hẹn giờ, có một cách rất đơn giản và dễ dàng để đặt lại nó về đúng giá trị. Bằng cách này, hầu hết các vấn đề liên quan đến bom độ khó sẽ biến mất. Chỉ cần đặt lại số khối khi đặt lại quả bom độ khó giống với FORK_BLOCK_NUMBER (số khối ngã ba) của ngã ba (hoặc điều chỉnh một chút). Theo cách này, số khối giả sẽ được đặt gần bằng 0 và kỷ nguyên cũng sẽ trở thành 0.

Tóm lại là

Vì tốc độ sản xuất khối chậm lại chủ yếu là do sự tồn tại của bom hẹn giờ, nên theo cách trên, hiệu ứng "ngẩng đầu" sẽ trở nên hoàn toàn có thể dự đoán được. Việc tính toán phần B hoàn toàn phụ thuộc vào số giả khối. Nếu chúng ta làm điều này vào thời điểm xảy ra ngã ba Constantinople (như bảng bên dưới) thì quả bom hẹn giờ đã không phát nổ nhanh như vậy.

tiêu đề phụ

Tóm lại là

开发者
ETH
Chào mừng tham gia cộng đồng chính thức của Odaily
Nhóm đăng ký:
https://t.me/Odaily_News
Nhóm trò chuyện:
https://t.me/Odaily_GoldenApe
Tài khoản chính thức:
https://twitter.com/OdailyChina
Mục lục bài viết
Thư viện tác giả
Tải ứng dụng Odaily Nhật Báo Hành Tinh
Hãy để một số người hiểu Web3.0 trước
IOS
Android