Jennifer Zynn
8k Bài đăng
Jennifer Zynn
Đã xác minh nâng cao trên SquareCrypto Expert , Trader , Sharing Market Insights, Trends / Twitter, X @JenniferZynn
97 Đang theo dõi
30.3K+ Người theo dõi
27.8K+ Đã thích
Bài đăng
Tất cả
Trích dẫn
Video
Live
Tôi có thể gửi tiền vào một khoản đầu tư TermMax Dual Investment, xem lợi suất đang chạy, và vẫn nhận ra rằng “rút tiền” không có nghĩa là toàn bộ số dư của tôi đều sẵn có.
Lý do chỉ trở nên rõ ràng khi tôi lần theo số tiền đã đi đâu. Các khoản gửi này sẽ tài trợ cho các vị thế tùy chọn TermMax Alpha. Nếu không có tài sản nào trong quỹ được vay, tôi có thể rút toàn bộ. Nếu tất cả chúng đã được Long hoặc Short vay mượn, việc rút sớm sẽ không khả dụng trừ khi có thanh khoản mới đi vào. Nếu chỉ một phần được vay, tôi chỉ có thể rút phần đang nhàn rỗi.
Điều đó khiến mức sử dụng (utilization) là con số tôi quan tâm sau khi đã gửi tiền.
Một APY cao có thể trông có vẻ thanh khoản ngay cho đến khi nhu cầu tùy chọn tiêu thụ lượng hàng tồn phía sau. Khi đó, việc thoát của tôi không còn chỉ phụ thuộc vào quyết định của tôi nữa. Nó phụ thuộc vào việc còn bao nhiêu phần của quỹ vẫn nhàn rỗi, liệu có khoản tiền gửi mới đến hay không, hoặc liệu tôi có đợi đến khi đáo hạn.
Vì vậy, tôi sẽ không bao giờ xem số dư TermMax Dual Investment như tiền mặt chỉ vì nó có một nhãn lợi suất. Khi nguồn vốn đó đang tài trợ cho tùy chọn của người khác, lợi suất và thời điểm rút đều gắn với cùng mức sử dụng.
#TermMax @TermMax $ONG $ACE $BOME
Lý do chỉ trở nên rõ ràng khi tôi lần theo số tiền đã đi đâu. Các khoản gửi này sẽ tài trợ cho các vị thế tùy chọn TermMax Alpha. Nếu không có tài sản nào trong quỹ được vay, tôi có thể rút toàn bộ. Nếu tất cả chúng đã được Long hoặc Short vay mượn, việc rút sớm sẽ không khả dụng trừ khi có thanh khoản mới đi vào. Nếu chỉ một phần được vay, tôi chỉ có thể rút phần đang nhàn rỗi.
Điều đó khiến mức sử dụng (utilization) là con số tôi quan tâm sau khi đã gửi tiền.
Một APY cao có thể trông có vẻ thanh khoản ngay cho đến khi nhu cầu tùy chọn tiêu thụ lượng hàng tồn phía sau. Khi đó, việc thoát của tôi không còn chỉ phụ thuộc vào quyết định của tôi nữa. Nó phụ thuộc vào việc còn bao nhiêu phần của quỹ vẫn nhàn rỗi, liệu có khoản tiền gửi mới đến hay không, hoặc liệu tôi có đợi đến khi đáo hạn.
Vì vậy, tôi sẽ không bao giờ xem số dư TermMax Dual Investment như tiền mặt chỉ vì nó có một nhãn lợi suất. Khi nguồn vốn đó đang tài trợ cho tùy chọn của người khác, lợi suất và thời điểm rút đều gắn với cùng mức sử dụng.
#TermMax @TermMax $ONG $ACE $BOME
Dòng tiền Dusk đã được hoàn tất có thể là thực sự đúng và vẫn là điều sai lầm để tôi ghi nhận như một khoản tiền gửi. Đó là bẫy mà bộ quét sẽ lừa tôi—và đó là thứ tôi sẽ phòng tránh đầu tiên. moonlightHistory(receiver) không phải là luồng “tiền gửi khách hàng”. Nó có thể trả về các chuyển khoản Moonlight trực tiếp, các khoản thanh toán hợp đồng, hoàn tiền, rút staking và các chuyển đổi từ Phoenix sang Moonlight vì tất cả chúng đều có thể làm tăng cùng một tài khoản công khai.
Vì vậy, tôi không thể giản lược việc nạp liệu thành “receiver khớp và value > 0”.
Đối với một khoản tiền gửi Moonlight trực tiếp, tôi cần chính sự kiện transfer-contract: topic moonlight, reverted là false, receiver dự kiến và giá trị dương. Dusk thậm chí còn cảnh báo không nên đoán họ giao dịch bằng cách đếm các sự kiện vì một giao dịch có thể phát ra thêm các sự kiện hợp đồng mà không làm thay đổi bản chất thực sự của nó.
Hậu quả là rất tệ trong kế toán lưu ký. Nếu bộ quét của tôi ghi có mọi dòng tiền vào đã hoàn tất, thì một khoản hoàn tiền nội bộ hoặc một lần rút staking có thể đi vào cùng đường ghi sổ với tiền tươi của khách hàng. Số dư trên chuỗi vẫn đúng trong khi nghĩa vụ của khách hàng của tôi trở nên sai.
Tôi thà từ chối một dòng tiền vào không quen thuộc hơn là lặng lẽ gọi nó là khoản tiền gửi.
Trên Dusk, “finalized” cho tôi biết tiền đã được chuyển đi. Còn “event type” cho tôi biết vì sao.
#dusk $DUSK @Dusk
Vì vậy, tôi không thể giản lược việc nạp liệu thành “receiver khớp và value > 0”.
Đối với một khoản tiền gửi Moonlight trực tiếp, tôi cần chính sự kiện transfer-contract: topic moonlight, reverted là false, receiver dự kiến và giá trị dương. Dusk thậm chí còn cảnh báo không nên đoán họ giao dịch bằng cách đếm các sự kiện vì một giao dịch có thể phát ra thêm các sự kiện hợp đồng mà không làm thay đổi bản chất thực sự của nó.
Hậu quả là rất tệ trong kế toán lưu ký. Nếu bộ quét của tôi ghi có mọi dòng tiền vào đã hoàn tất, thì một khoản hoàn tiền nội bộ hoặc một lần rút staking có thể đi vào cùng đường ghi sổ với tiền tươi của khách hàng. Số dư trên chuỗi vẫn đúng trong khi nghĩa vụ của khách hàng của tôi trở nên sai.
Tôi thà từ chối một dòng tiền vào không quen thuộc hơn là lặng lẽ gọi nó là khoản tiền gửi.
Trên Dusk, “finalized” cho tôi biết tiền đã được chuyển đi. Còn “event type” cho tôi biết vì sao.
#dusk $DUSK @Dusk
Tôi có thể trả đúng khoản vay TermMax và vẫn phải trả thêm để lấy lại tài sản thế chấp.
Cái bẫy nằm ở đường đi nước rút khi thanh toán. GT của tôi mang cả tài sản thế chấp và khoản nợ, còn FT tương ứng thể hiện yêu cầu đòi nợ đó. Trước thời hạn đáo hạn, TermMax cho tôi hai cách thoát: trả bằng token nợ theo mệnh giá, hoặc mua FT tương ứng trên thị trường và dùng FT đó để hủy khoản nợ.
Con đường thứ hai làm thay đổi phép tính.
Nếu tôi nợ 100.000 USDC và FT tương ứng đang giao dịch ở mức 0,97, thì việc gửi thẳng 100.000 USDC là cách thoát dễ dàng. Nhưng để có 100.000 FT thì tốn khoảng 97.000 USDC trước phí và trượt giá, rồi những FT đó có thể dùng để thanh toán khoản nợ mệnh giá tương ứng.
Vì vậy, sau khi tôi khóa một mức lãi suất cố định, tôi vẫn còn một nhiệm vụ khi muốn rút sớm. Tôi cần định giá token nợ của chính mình trước khi nhấn nút thanh toán.
Hệ quả nhìn thấy được rất đơn giản: bỏ qua thị trường FT có thể biến việc đóng sớm thành hàng nghìn đô la tiền trả nợ không cần thiết trên một vị thế lớn.
Tôi không còn coi đáo hạn của TermMax chỉ là một thời hạn nữa. Cho đến thời điểm đó, giá để hủy phần kỳ hạn còn lại vẫn là thứ tôi có thể giao dịch.
#TermMax @TermMax
$RE $MUBARAK $HEMI
Cái bẫy nằm ở đường đi nước rút khi thanh toán. GT của tôi mang cả tài sản thế chấp và khoản nợ, còn FT tương ứng thể hiện yêu cầu đòi nợ đó. Trước thời hạn đáo hạn, TermMax cho tôi hai cách thoát: trả bằng token nợ theo mệnh giá, hoặc mua FT tương ứng trên thị trường và dùng FT đó để hủy khoản nợ.
Con đường thứ hai làm thay đổi phép tính.
Nếu tôi nợ 100.000 USDC và FT tương ứng đang giao dịch ở mức 0,97, thì việc gửi thẳng 100.000 USDC là cách thoát dễ dàng. Nhưng để có 100.000 FT thì tốn khoảng 97.000 USDC trước phí và trượt giá, rồi những FT đó có thể dùng để thanh toán khoản nợ mệnh giá tương ứng.
Vì vậy, sau khi tôi khóa một mức lãi suất cố định, tôi vẫn còn một nhiệm vụ khi muốn rút sớm. Tôi cần định giá token nợ của chính mình trước khi nhấn nút thanh toán.
Hệ quả nhìn thấy được rất đơn giản: bỏ qua thị trường FT có thể biến việc đóng sớm thành hàng nghìn đô la tiền trả nợ không cần thiết trên một vị thế lớn.
Tôi không còn coi đáo hạn của TermMax chỉ là một thời hạn nữa. Cho đến thời điểm đó, giá để hủy phần kỳ hạn còn lại vẫn là thứ tôi có thể giao dịch.
#TermMax @TermMax
$RE $MUBARAK $HEMI
Hợp đồng DuskVM có thể chịu được tình trạng failover của node trong khi ứng dụng của tôi bỗng quên cách nói chuyện với nó.
Lý do nằm ở ngoài chuỗi. Forge tạo ra hai hiện vật WASM từ cùng một nguồn: hợp đồng chạy trong DuskVM và một data driver xử lý việc chuyển đổi JSON đọc được sang rkyv và ngược lại (encoding và decoding). Data driver đó không được triển khai như một phần của hợp đồng trên chuỗi.
Nếu tôi muốn các tuyến (routes) hợp đồng JSON của Rusk thực hiện việc dịch đó, thì chủ sở hữu hợp đồng phải đăng ký driver với node đó.
Vì vậy, tôi có thể triển khai một lần, kiểm thử trên Node A, thấy các lệnh gọi vẫn rõ ràng dễ đọc, rồi failover sang Node B và gặp một trạng thái kỳ lạ. Hợp đồng vẫn ở đó. Chuỗi vẫn khỏe. Nhưng driver_available có thể là false, nên ứng dụng bị mất “bề mặt” giải mã mà nó đã được xây dựng dựa trên.
Đó là cái bẫy trong môi trường production của tôi. Consensus không hề thất bại. Hợp đồng không hề thất bại. Failover của tôi đã thay đổi một phụ thuộc ngoài chuỗi mà tôi đã từng coi như nó đi kèm theo hợp đồng.
Tôi sẽ coi tính sẵn sàng của driver là một phần của mức “sẵn sàng” (readiness) của node, và kiểm tra nó ở mọi endpoint của Rusk trước khi lưu lượng truy cập (traffic) được chuyển tới.
Trên DuskVM, hợp đồng có thể chịu được failover, trong khi bộ dịch (translator) của nó thì không.
#dusk $DUSK @Dusk
Lý do nằm ở ngoài chuỗi. Forge tạo ra hai hiện vật WASM từ cùng một nguồn: hợp đồng chạy trong DuskVM và một data driver xử lý việc chuyển đổi JSON đọc được sang rkyv và ngược lại (encoding và decoding). Data driver đó không được triển khai như một phần của hợp đồng trên chuỗi.
Nếu tôi muốn các tuyến (routes) hợp đồng JSON của Rusk thực hiện việc dịch đó, thì chủ sở hữu hợp đồng phải đăng ký driver với node đó.
Vì vậy, tôi có thể triển khai một lần, kiểm thử trên Node A, thấy các lệnh gọi vẫn rõ ràng dễ đọc, rồi failover sang Node B và gặp một trạng thái kỳ lạ. Hợp đồng vẫn ở đó. Chuỗi vẫn khỏe. Nhưng driver_available có thể là false, nên ứng dụng bị mất “bề mặt” giải mã mà nó đã được xây dựng dựa trên.
Đó là cái bẫy trong môi trường production của tôi. Consensus không hề thất bại. Hợp đồng không hề thất bại. Failover của tôi đã thay đổi một phụ thuộc ngoài chuỗi mà tôi đã từng coi như nó đi kèm theo hợp đồng.
Tôi sẽ coi tính sẵn sàng của driver là một phần của mức “sẵn sàng” (readiness) của node, và kiểm tra nó ở mọi endpoint của Rusk trước khi lưu lượng truy cập (traffic) được chuyển tới.
Trên DuskVM, hợp đồng có thể chịu được failover, trong khi bộ dịch (translator) của nó thì không.
#dusk $DUSK @Dusk
Tôi có thể thấy 1,1M USDC sẵn có trong một thị trường TermMax PT-eUSDe và vẫn có thể mất 500K khỏi năng lực đó vì ai đó đã mượn trước bằng wBTC.
Nghe có vẻ sai cho đến khi tôi lần theo cách Atomic Orders thực sự sử dụng một vault.
Ở V1, một curator có 1,1M USDC phải chia nhỏ trước khi nhu cầu đến: 250K cho PT-eUSDe, 600K cho wBTC, 250K cho wstETH. Tiền là có thật, nhưng mỗi phần đều bị “giam” bên trong thị trường mà nó được chọn.
V2 cho phép cùng một 1,1M nằm đồng thời trên cả ba thị trường. Không phải ba bản sao của tiền. Một nguồn cung dùng chung. Nếu tôi lấy 500K ở PT-eUSDe, thì tính thanh khoản sẵn có trong PT-eUSDe, wBTC và wstETH đều giảm xuống 600K một cách nguyên tử.
Điều này thay đổi cách tôi đọc con số hiển thị trên màn hình. Quy mô tôi thấy ở một thị trường không được giữ riêng cho thị trường đó. Nó có thể giảm vì một người đi vay sử dụng tài sản thế chấp khác đã tiếp cận cùng vault đó trước.
Vì vậy, rủi ro thực thi của tôi không còn chỉ là liệu thị trường tôi chọn có nhu cầu hay không. Tôi còn phải quan tâm đến việc ai khác đang cạnh tranh để giành nguồn thanh khoản vault cơ sở giống nhau.
Lãi suất có thể được cố định trong khi phần hàng tồn phía sau nó vẫn đang “chạy đua” giữa các thị trường.
#TermMax @TermMax
Nghe có vẻ sai cho đến khi tôi lần theo cách Atomic Orders thực sự sử dụng một vault.
Ở V1, một curator có 1,1M USDC phải chia nhỏ trước khi nhu cầu đến: 250K cho PT-eUSDe, 600K cho wBTC, 250K cho wstETH. Tiền là có thật, nhưng mỗi phần đều bị “giam” bên trong thị trường mà nó được chọn.
V2 cho phép cùng một 1,1M nằm đồng thời trên cả ba thị trường. Không phải ba bản sao của tiền. Một nguồn cung dùng chung. Nếu tôi lấy 500K ở PT-eUSDe, thì tính thanh khoản sẵn có trong PT-eUSDe, wBTC và wstETH đều giảm xuống 600K một cách nguyên tử.
Điều này thay đổi cách tôi đọc con số hiển thị trên màn hình. Quy mô tôi thấy ở một thị trường không được giữ riêng cho thị trường đó. Nó có thể giảm vì một người đi vay sử dụng tài sản thế chấp khác đã tiếp cận cùng vault đó trước.
Vì vậy, rủi ro thực thi của tôi không còn chỉ là liệu thị trường tôi chọn có nhu cầu hay không. Tôi còn phải quan tâm đến việc ai khác đang cạnh tranh để giành nguồn thanh khoản vault cơ sở giống nhau.
Lãi suất có thể được cố định trong khi phần hàng tồn phía sau nó vẫn đang “chạy đua” giữa các thị trường.
#TermMax @TermMax
Một giao dịch lúc hoàng hôn có thể biến mất khỏi mempool của node tôi mà không bao giờ đạt đến thời hạn hết trên chuỗi.
Đó là khoảng thời gian giới hạn mà tôi sẽ không mã hóa cứng vào một ví. @Dusk giao dịch không mang trường expiry (hết hạn). Việc hết hạn là chính sách cục bộ của Rusk. Mặc định tích hợp là ba ngày, trong khi các node cài đặt bằng node-installer v0.5.22 dùng thời gian sống mempool là 30 phút, với các lần kiểm tra mỗi năm phút.
Vì vậy, hai node Dusk khỏe mạnh có thể đưa ra những câu trả lời rất khác nhau về việc giao dịch đang chờ giống nhau được phép nằm yên trong bao lâu.
Phần tệ hơn là sự kiện “removed” (đã bị gỡ bỏ). Nó chỉ cho tôi biết giao dịch đã rời mempool cục bộ của node đó. Việc được đưa vào khối (inclusion), thay thế (replacement), hết hạn (expiry), bị loại do vượt dung lượng (capacity eviction), hoặc một giao dịch chi tiêu xung đột (conflicting spend) đều có thể tạo ra ngõ ra đó. Nếu tôi dịch “removed” thẳng sang “failed” (thất bại), logic khôi phục của tôi sẽ đoán sai.
Đối với một dịch vụ rút tiền, sự đoán sai đó có thể ảnh hưởng đến người dùng. Tôi có thể đánh dấu một khoản thanh toán là đã chết (dead) vì node của tôi đã hết hạn cục bộ trong khi một node khác đã lan truyền nó xa hơn.
Tôi sẽ coi timeout của mempool là cấu hình của node, rồi truy vấn trạng thái ledger trước khi quyết định rằng một giao dịch DUSK là an toàn để xây dựng lại (rebuild).
Trên Dusk, “đã biến mất khỏi mempool của tôi” không giống với “đã biến mất hoàn toàn”.
$SOXSB $ACE #dusk $DUSK @Dusk
Đó là khoảng thời gian giới hạn mà tôi sẽ không mã hóa cứng vào một ví. @Dusk giao dịch không mang trường expiry (hết hạn). Việc hết hạn là chính sách cục bộ của Rusk. Mặc định tích hợp là ba ngày, trong khi các node cài đặt bằng node-installer v0.5.22 dùng thời gian sống mempool là 30 phút, với các lần kiểm tra mỗi năm phút.
Vì vậy, hai node Dusk khỏe mạnh có thể đưa ra những câu trả lời rất khác nhau về việc giao dịch đang chờ giống nhau được phép nằm yên trong bao lâu.
Phần tệ hơn là sự kiện “removed” (đã bị gỡ bỏ). Nó chỉ cho tôi biết giao dịch đã rời mempool cục bộ của node đó. Việc được đưa vào khối (inclusion), thay thế (replacement), hết hạn (expiry), bị loại do vượt dung lượng (capacity eviction), hoặc một giao dịch chi tiêu xung đột (conflicting spend) đều có thể tạo ra ngõ ra đó. Nếu tôi dịch “removed” thẳng sang “failed” (thất bại), logic khôi phục của tôi sẽ đoán sai.
Đối với một dịch vụ rút tiền, sự đoán sai đó có thể ảnh hưởng đến người dùng. Tôi có thể đánh dấu một khoản thanh toán là đã chết (dead) vì node của tôi đã hết hạn cục bộ trong khi một node khác đã lan truyền nó xa hơn.
Tôi sẽ coi timeout của mempool là cấu hình của node, rồi truy vấn trạng thái ledger trước khi quyết định rằng một giao dịch DUSK là an toàn để xây dựng lại (rebuild).
Trên Dusk, “đã biến mất khỏi mempool của tôi” không giống với “đã biến mất hoàn toàn”.
$SOXSB $ACE #dusk $DUSK @Dusk
Ví <W3sper> có thể dẫn xuất một hồ sơ Dusk thật, hãy cho tôi một địa chỉ, và vẫn không thể xây dựng được lần chuyển tiền đầu tiên.
Phần công việc ẩn là trạng thái Bookkeeper. W3sper cung cấp cho tôi trình tạo giao dịch, nhưng nó không biến một Profile mới tạo thành một ví headless hoàn chỉnh. Nếu tôi tạo khóa rồi nhảy thẳng sang gửi, thì Profile đó không có mục Bookkeeper đã được đồng bộ, nên trình tạo không thể lấy được số dư và trạng thái nonce mà nó cần.
Phoenix làm việc này khó giả mạo hơn. Một dịch vụ ký cũng phải giữ các ghi chú shielded được đồng bộ, không chỉ giữ khóa bí mật. Vì vậy việc quản lý khóa có thể đúng, nhưng trạng thái có thể dùng để chi tiêu thì đã lỗi thời.
Điểm tệ là ví có thể trông như đã hoàn tất. Tôi có thể tạo tài khoản, nạp tiền vào, bảo vệ khóa, rồi nhấn Send và phát hiện phần backend của tôi chưa bao giờ xây dựng lại trạng thái giúp cho DUSK đó có thể chi tiêu.
Nếu tôi đang vận hành một kho quỹ headless của Dusk, tôi sẽ kiểm thử khả năng khôi phục bằng cách khôi phục các khóa vào một cơ sở dữ liệu trống và để ví đồng bộ lại trước khi nó ký bất cứ thứ gì.
Trên Dusk, sao lưu khóa không giống với sao lưu quy trình vận hành của ví.
#dusk $DUSK @Dusk
Phần công việc ẩn là trạng thái Bookkeeper. W3sper cung cấp cho tôi trình tạo giao dịch, nhưng nó không biến một Profile mới tạo thành một ví headless hoàn chỉnh. Nếu tôi tạo khóa rồi nhảy thẳng sang gửi, thì Profile đó không có mục Bookkeeper đã được đồng bộ, nên trình tạo không thể lấy được số dư và trạng thái nonce mà nó cần.
Phoenix làm việc này khó giả mạo hơn. Một dịch vụ ký cũng phải giữ các ghi chú shielded được đồng bộ, không chỉ giữ khóa bí mật. Vì vậy việc quản lý khóa có thể đúng, nhưng trạng thái có thể dùng để chi tiêu thì đã lỗi thời.
Điểm tệ là ví có thể trông như đã hoàn tất. Tôi có thể tạo tài khoản, nạp tiền vào, bảo vệ khóa, rồi nhấn Send và phát hiện phần backend của tôi chưa bao giờ xây dựng lại trạng thái giúp cho DUSK đó có thể chi tiêu.
Nếu tôi đang vận hành một kho quỹ headless của Dusk, tôi sẽ kiểm thử khả năng khôi phục bằng cách khôi phục các khóa vào một cơ sở dữ liệu trống và để ví đồng bộ lại trước khi nó ký bất cứ thứ gì.
Trên Dusk, sao lưu khóa không giống với sao lưu quy trình vận hành của ví.
#dusk $DUSK @Dusk
Một nút archive tại thời điểm hoàng hôn có thể được bắt kịp đến đầu chuỗi (chain tip) nhưng vẫn thiếu lịch sử mà tôi cần để ghi nhận một khoản gửi cũ.
Cái bẫy nằm ở đường dẫn khởi động (bootstrap). Archive Rusk giữ các chỉ mục đã được finality sử dụng bởi moonlightHistory, fullMoonlightHistory và finalizedEvents. Nhưng nếu tôi đưa nút lên từ bản snapshot download_state của trình cài đặt, tôi sẽ khôi phục trạng thái thực thi, không phải các chỉ mục archive cho các block trước snapshot đó.
Vì vậy, “synced” không phải là bài kiểm tra mức sẵn sàng mà tôi quan tâm.
Với một dịch vụ gửi Moonlight, tôi có thể truy vấn lịch sử đã finalized, nhận được phản hồi sạch sẽ, và vẫn có một dải bị mù nằm phía sau ranh giới của snapshot. Trạng thái chuỗi hiện tại là đúng. Việc nạp lịch sử của tôi thì chưa. Một thao tác backfill thông qua nút đó có thể âm thầm bỏ qua một khoản gửi cũ, trong khi mọi bài kiểm tra sức khỏe (health check) ở gần đỉnh chuỗi đều trông bình thường.
Nếu tôi cần toàn bộ lịch sử, archive phải đồng bộ từ genesis hoặc lấy từ một bản backup đáng tin cậy vốn đã chứa các cơ sở dữ liệu archive. Sau đó, tôi cần kiểm thử dải block sớm nhất mà dịch vụ của tôi cam kết sẽ bao phủ trước khi coi nó sẵn sàng.
Tôi thà cho bài kiểm tra sẵn sàng thất bại một cách rõ ràng còn hơn là phát hiện ra dải bị thiếu khi người dùng hỏi vì sao một khoản gửi DUSK đã được finalized lại không bao giờ chạm đến số dư của họ.
#dusk $DUSK @Dusk
Cái bẫy nằm ở đường dẫn khởi động (bootstrap). Archive Rusk giữ các chỉ mục đã được finality sử dụng bởi moonlightHistory, fullMoonlightHistory và finalizedEvents. Nhưng nếu tôi đưa nút lên từ bản snapshot download_state của trình cài đặt, tôi sẽ khôi phục trạng thái thực thi, không phải các chỉ mục archive cho các block trước snapshot đó.
Vì vậy, “synced” không phải là bài kiểm tra mức sẵn sàng mà tôi quan tâm.
Với một dịch vụ gửi Moonlight, tôi có thể truy vấn lịch sử đã finalized, nhận được phản hồi sạch sẽ, và vẫn có một dải bị mù nằm phía sau ranh giới của snapshot. Trạng thái chuỗi hiện tại là đúng. Việc nạp lịch sử của tôi thì chưa. Một thao tác backfill thông qua nút đó có thể âm thầm bỏ qua một khoản gửi cũ, trong khi mọi bài kiểm tra sức khỏe (health check) ở gần đỉnh chuỗi đều trông bình thường.
Nếu tôi cần toàn bộ lịch sử, archive phải đồng bộ từ genesis hoặc lấy từ một bản backup đáng tin cậy vốn đã chứa các cơ sở dữ liệu archive. Sau đó, tôi cần kiểm thử dải block sớm nhất mà dịch vụ của tôi cam kết sẽ bao phủ trước khi coi nó sẵn sàng.
Tôi thà cho bài kiểm tra sẵn sàng thất bại một cách rõ ràng còn hơn là phát hiện ra dải bị thiếu khi người dùng hỏi vì sao một khoản gửi DUSK đã được finalized lại không bao giờ chạm đến số dư của họ.
#dusk $DUSK @Dusk
Con số 91 là hợp lý. Thứ kìm hãm nó chủ yếu nằm ở việc xếp chuỗi (sequencing). Hệ quả tốt nhất của bạn xuất hiện quá muộn.
Tôi sẽ siết lại như sau:
Tôi phát hiện một chi tiết staking trên Dusk khiến việc nạp thêm lặp lại trở nên bất tiện hơn vẻ ngoài.
Nếu provisioner của tôi đã đang hoạt động và tôi thêm 4.000 DUSK, thì chỉ có 3.600 được nạp thẳng vào phần active stake. 400 còn lại sẽ bị khóa.
400 đó vẫn là của tôi, nhưng phần khó chịu là lấy lại được số dư cuối cùng đã bị khóa. Tôi có thể cuối cùng sẽ cần phải tháo/thoát hoàn toàn vị thế còn lại chỉ để thu hồi nó.
Vì vậy, con số tôi thêm vào và con số thực sự hoạt động trong consensus ngay lập tức không giống nhau.
Điều này càng dễ nhận ra nếu tôi tiếp tục ghép lãi (compounding). Một lần nạp thêm nữa sẽ tạo ra một lần tách 90/10 khác. Tôi có thể tiếp tục mở rộng phần active trong khi đồng thời xây dựng một số dư bị khóa nằm ngoài consensus và theo tôi cho đến lúc thoát cuối cùng.
Trước đây, tôi thường nhìn compounding chủ yếu như một quyết định nhận thưởng.
Trên Dusk, tôi cũng sẽ theo dõi mức độ “dọn dẹp” mà tôi đang âm thầm tạo ra mỗi lần tôi nạp thêm.
#dusk $DUSK @Dusk
Tôi sẽ siết lại như sau:
Tôi phát hiện một chi tiết staking trên Dusk khiến việc nạp thêm lặp lại trở nên bất tiện hơn vẻ ngoài.
Nếu provisioner của tôi đã đang hoạt động và tôi thêm 4.000 DUSK, thì chỉ có 3.600 được nạp thẳng vào phần active stake. 400 còn lại sẽ bị khóa.
400 đó vẫn là của tôi, nhưng phần khó chịu là lấy lại được số dư cuối cùng đã bị khóa. Tôi có thể cuối cùng sẽ cần phải tháo/thoát hoàn toàn vị thế còn lại chỉ để thu hồi nó.
Vì vậy, con số tôi thêm vào và con số thực sự hoạt động trong consensus ngay lập tức không giống nhau.
Điều này càng dễ nhận ra nếu tôi tiếp tục ghép lãi (compounding). Một lần nạp thêm nữa sẽ tạo ra một lần tách 90/10 khác. Tôi có thể tiếp tục mở rộng phần active trong khi đồng thời xây dựng một số dư bị khóa nằm ngoài consensus và theo tôi cho đến lúc thoát cuối cùng.
Trước đây, tôi thường nhìn compounding chủ yếu như một quyết định nhận thưởng.
Trên Dusk, tôi cũng sẽ theo dõi mức độ “dọn dẹp” mà tôi đang âm thầm tạo ra mỗi lần tôi nạp thêm.
#dusk $DUSK @Dusk
Tôi nhận thấy phần khó chịu của Dusk là không gửi một chuyển khoản riêng tư. Đó là những gì xảy ra khi giao dịch đó phải trở thành tín dụng trao đổi mà không để người vận hành đoán được ai là chủ sở hữu.
Với các khoản nạp, Dusk không giả vờ rằng Phoenix và Moonlight có thể thay thế cho nhau. Phoenix sử dụng các ghi chú được che chắn và bộ triệt tiêu (nullifiers), trong khi các tích hợp trao đổi được điều hướng sang Moonlight vì mô hình quản lý ký quỹ và quét là khác nhau. Vì vậy, người vận hành vẫn phải chọn cách thức gán thuộc tính (attribution): một tài khoản Moonlight cho mỗi khách hàng, hoặc một tài khoản dùng chung nơi phần ghi chú (memo) trở thành dữ liệu định tuyến.
Rồi trường hợp lỗi xấu xuất hiện. Một chuyển khoản hợp lệ có thể đến với siêu dữ liệu bị thiếu, bị sai định dạng, không xác định hoặc đã được tái sử dụng. Chuỗi (chain) vẫn có thể được giải quyết đúng cách, nhưng khoản tín dụng vẫn phải bị cô lập (quarantine) thay vì được đăng cho nhầm người dùng.
Chi tiết mà tôi cứ quay lại chính là điểm kiểm tra (checkpoint). Dusk kỳ vọng các khoản tín dụng và checkpoint của block đã quét sẽ được ghi theo cách nguyên tử (atomically), sử dụng transaction ID để đảm bảo tính bất biến (idempotency). Tiến checkpoint trước khi khoản tín dụng được bảo đảm (durable) thì một sự cố (crash) có thể khiến khoản nạp đó bị bỏ sót khỏi luồng nạp (ingestion path) của người vận hành.
Với Dusk, bài test quản lý ký quỹ thực sự là liệu một khoản nạp Moonlight đã được hoàn tất có thể biến mất giữa thời điểm checkpoint và thời điểm khoản tín dụng hay không.
#dusk $DUSK @Dusk
#USJulyCPI&PPIDueThisWeek
Với các khoản nạp, Dusk không giả vờ rằng Phoenix và Moonlight có thể thay thế cho nhau. Phoenix sử dụng các ghi chú được che chắn và bộ triệt tiêu (nullifiers), trong khi các tích hợp trao đổi được điều hướng sang Moonlight vì mô hình quản lý ký quỹ và quét là khác nhau. Vì vậy, người vận hành vẫn phải chọn cách thức gán thuộc tính (attribution): một tài khoản Moonlight cho mỗi khách hàng, hoặc một tài khoản dùng chung nơi phần ghi chú (memo) trở thành dữ liệu định tuyến.
Rồi trường hợp lỗi xấu xuất hiện. Một chuyển khoản hợp lệ có thể đến với siêu dữ liệu bị thiếu, bị sai định dạng, không xác định hoặc đã được tái sử dụng. Chuỗi (chain) vẫn có thể được giải quyết đúng cách, nhưng khoản tín dụng vẫn phải bị cô lập (quarantine) thay vì được đăng cho nhầm người dùng.
Chi tiết mà tôi cứ quay lại chính là điểm kiểm tra (checkpoint). Dusk kỳ vọng các khoản tín dụng và checkpoint của block đã quét sẽ được ghi theo cách nguyên tử (atomically), sử dụng transaction ID để đảm bảo tính bất biến (idempotency). Tiến checkpoint trước khi khoản tín dụng được bảo đảm (durable) thì một sự cố (crash) có thể khiến khoản nạp đó bị bỏ sót khỏi luồng nạp (ingestion path) của người vận hành.
Với Dusk, bài test quản lý ký quỹ thực sự là liệu một khoản nạp Moonlight đã được hoàn tất có thể biến mất giữa thời điểm checkpoint và thời điểm khoản tín dụng hay không.
#dusk $DUSK @Dusk
#USJulyCPI&PPIDueThisWeek
TÔI ĐÃ CẢNH BÁO CÁC BẠN VỀ VỤ BÁN MẠNH BITCOIN NÀY.
Giờ đây, $BTC đang đi theo đúng lộ trình mà tôi đã theo dõi hướng tới đáy của chu kỳ.
Cho đến nay, kế hoạch vẫn còn nguyên vẹn.
Tôi đã dự đoán đúng đáy $16K.
Tôi đã dự đoán đúng đỉnh $126K.
Nhưng lần dự đoán tiếp theo mới quan trọng hơn.
Khi tôi thấy mức giá mà tôi sẵn sàng để mua mạnh trở lại, tôi sẽ đăng công khai ngay tại đây.
Đa số người sẽ chờ xác nhận.
Nhưng đến lúc đó, cơ hội có thể đã trôi qua.
Bật thông báo lên.
Giờ đây, $BTC đang đi theo đúng lộ trình mà tôi đã theo dõi hướng tới đáy của chu kỳ.
Cho đến nay, kế hoạch vẫn còn nguyên vẹn.
Tôi đã dự đoán đúng đáy $16K.
Tôi đã dự đoán đúng đỉnh $126K.
Nhưng lần dự đoán tiếp theo mới quan trọng hơn.
Khi tôi thấy mức giá mà tôi sẵn sàng để mua mạnh trở lại, tôi sẽ đăng công khai ngay tại đây.
Đa số người sẽ chờ xác nhận.
Nhưng đến lúc đó, cơ hội có thể đã trôi qua.
Bật thông báo lên.
Tôi đã kiểm tra xem ví kho bạc có thực sự thể thu hồi khoản đặt cược của Babylon hay không.
Nó có thể ký các UTXO dùng để cấp vốn cho khoản tiền gửi.
Sau đó, tôi chạy kiểm tra quyền sở hữu đối chiếu với StakerPk đã được cam kết bên trong đầu ra staking.
“Không tìm thấy key.”
Ví kho bạc được cho là phải kiểm soát key đó. Hệ thống thu hồi vẫn không thể tạo ra nó khi được yêu cầu.
Không có gì trong luồng gửi tiền có thể lộ ra điều đó.
Giao dịch cấp vốn sẽ ký. Khoản staking được xác nhận. Phần ủy quyền trở nên hoạt động.
Vấn đề chỉ xuất hiện khi BTC cần phải di chuyển lần nữa.
Cả đường rút tiền thông thường lẫn việc unbond sớm vẫn còn phụ thuộc vào key của staker. Việc phê duyệt covenant không thay thế được nó.
Vì vậy, BTC chưa bao giờ được chứng minh có thể thu hồi khi nó bước vào Babylon. Nó chỉ được chứng minh là có thể được cấp vốn.
“Không tìm thấy key” có vẻ vô hại cho đến khi nó được gắn với key duy nhất có thể đưa BTC về nhà.
#BABY $BABY @BabylonLabs_io
$HOME
$TUT
Nó có thể ký các UTXO dùng để cấp vốn cho khoản tiền gửi.
Sau đó, tôi chạy kiểm tra quyền sở hữu đối chiếu với StakerPk đã được cam kết bên trong đầu ra staking.
“Không tìm thấy key.”
Ví kho bạc được cho là phải kiểm soát key đó. Hệ thống thu hồi vẫn không thể tạo ra nó khi được yêu cầu.
Không có gì trong luồng gửi tiền có thể lộ ra điều đó.
Giao dịch cấp vốn sẽ ký. Khoản staking được xác nhận. Phần ủy quyền trở nên hoạt động.
Vấn đề chỉ xuất hiện khi BTC cần phải di chuyển lần nữa.
Cả đường rút tiền thông thường lẫn việc unbond sớm vẫn còn phụ thuộc vào key của staker. Việc phê duyệt covenant không thay thế được nó.
Vì vậy, BTC chưa bao giờ được chứng minh có thể thu hồi khi nó bước vào Babylon. Nó chỉ được chứng minh là có thể được cấp vốn.
“Không tìm thấy key” có vẻ vô hại cho đến khi nó được gắn với key duy nhất có thể đưa BTC về nhà.
#BABY $BABY @BabylonLabs_io
$HOME
$TUT
Bài tập phục hồi của tôi đã vượt qua kiểm tra key quan trọng nhưng vẫn không tạo ra các phiếu bầu cuối cùng.
Chữ ký cuối cùng của Babylon cần nhiều hơn khóa EOTS. Nó phải mang theo bằng chứng Merkle, chứng minh rằng tính ngẫu nhiên công khai của nó đã được cam kết cho đúng độ cao đó. Những bằng chứng này, cùng với độ cao cuối cùng mà nhà cung cấp đã bỏ phiếu, nằm trong finality-provider.db.
Khôi phục keyring lên một máy sạch không phải là một bản khôi phục hoạt động. Daemon có thể nhận ra provider của tôi, truy cập eotsd và giữ đủ gas trong khi mọi lần gửi phiếu đều thất bại vì thiếu bằng chứng tính ngẫu nhiên. Provider trông có vẻ đã được khôi phục trong keyring và vẫn im lặng ở độ cao Babylon tiếp theo.
Việc sửa là cụ thể. Tôi phải dừng fpd và chạy recover-rand-proof từ một độ cao bắt đầu được chọn. Nếu tôi bỏ qua độ cao đó, công cụ sẽ xây dựng lại các bằng chứng từ cam kết tính ngẫu nhiên đầu tiên, biến toàn bộ lịch sử vận hành của provider thành công việc khôi phục.
Tôi sẽ kiểm tra bản sao lưu bằng cách gửi một phiếu bầu cuối cùng thật, chứ không phải bằng cách kiểm tra liệu quá trình có bắt đầu hay không. Khôi phục danh tính mà không khôi phục bằng chứng ký chỉ mới là một nửa của việc khôi phục.
Máy có thể nhớ mình là ai nhưng vẫn quên cách chứng minh phiếu bầu tiếp theo của nó.
#baby $BABY @BabylonLabs_io
$DOGE
$TAKE
Chữ ký cuối cùng của Babylon cần nhiều hơn khóa EOTS. Nó phải mang theo bằng chứng Merkle, chứng minh rằng tính ngẫu nhiên công khai của nó đã được cam kết cho đúng độ cao đó. Những bằng chứng này, cùng với độ cao cuối cùng mà nhà cung cấp đã bỏ phiếu, nằm trong finality-provider.db.
Khôi phục keyring lên một máy sạch không phải là một bản khôi phục hoạt động. Daemon có thể nhận ra provider của tôi, truy cập eotsd và giữ đủ gas trong khi mọi lần gửi phiếu đều thất bại vì thiếu bằng chứng tính ngẫu nhiên. Provider trông có vẻ đã được khôi phục trong keyring và vẫn im lặng ở độ cao Babylon tiếp theo.
Việc sửa là cụ thể. Tôi phải dừng fpd và chạy recover-rand-proof từ một độ cao bắt đầu được chọn. Nếu tôi bỏ qua độ cao đó, công cụ sẽ xây dựng lại các bằng chứng từ cam kết tính ngẫu nhiên đầu tiên, biến toàn bộ lịch sử vận hành của provider thành công việc khôi phục.
Tôi sẽ kiểm tra bản sao lưu bằng cách gửi một phiếu bầu cuối cùng thật, chứ không phải bằng cách kiểm tra liệu quá trình có bắt đầu hay không. Khôi phục danh tính mà không khôi phục bằng chứng ký chỉ mới là một nửa của việc khôi phục.
Máy có thể nhớ mình là ai nhưng vẫn quên cách chứng minh phiếu bầu tiếp theo của nó.
#baby $BABY @BabylonLabs_io
$DOGE
$TAKE
Tôi đã phát hiện thất bại khi người ký trả về khoản Babylon pre-stake dưới dạng đã ký đầy đủ.
Babylon vẫn hiển thị ủy quyền là PENDING.
Đó là vấn đề.
Việc chọn coin đã kéo một UTXO legacy vào một stake nhiều ngõ vào. Vì UTXO đó cần chữ ký của nó bên trong scriptSig, người ký của tôi đã hoàn tất giao dịch trước khi Babylon kịp hoàn tất kiểm tra covenant.
Chuỗi hex của giao dịch không còn chỉ là một gói đăng ký nữa. Một node Bitcoin có thể chấp nhận và chuyển tiếp (relay) nó.
Tôi đã loại bỏ giao dịch đã ký, xây dựng lại việc chọn coin chỉ với các input SegWit, và bắt đầu lại luồng đăng ký.
Không có chữ ký không hợp lệ. Không có giao dịch Bitcoin nào bị từ chối.
Chỉ có việc BTC trở nên có thể được khai thác trong khi Babylon vẫn coi ủy quyền là chưa hoàn tất.
#BABY $BABY @BabylonLabs_io
Babylon vẫn hiển thị ủy quyền là PENDING.
Đó là vấn đề.
Việc chọn coin đã kéo một UTXO legacy vào một stake nhiều ngõ vào. Vì UTXO đó cần chữ ký của nó bên trong scriptSig, người ký của tôi đã hoàn tất giao dịch trước khi Babylon kịp hoàn tất kiểm tra covenant.
Chuỗi hex của giao dịch không còn chỉ là một gói đăng ký nữa. Một node Bitcoin có thể chấp nhận và chuyển tiếp (relay) nó.
Tôi đã loại bỏ giao dịch đã ký, xây dựng lại việc chọn coin chỉ với các input SegWit, và bắt đầu lại luồng đăng ký.
Không có chữ ký không hợp lệ. Không có giao dịch Bitcoin nào bị từ chối.
Chỉ có việc BTC trở nên có thể được khai thác trong khi Babylon vẫn coi ủy quyền là chưa hoàn tất.
#BABY $BABY @BabylonLabs_io
Tôi đã có BABY ngồi trong một yêu cầu “được chấp nhận” (accepted undelegation) trong khi một vị trí khác đang trượt dần tới thanh lý ở mức $0.01188.
Tôi nghĩ “được chấp nhận” nghĩa là thời gian chờ đã bắt đầu. Vì vậy tôi đã đếm tiếp từ lúc bấm và lên kế hoạch cho việc di chuyển tài sản thế chấp dựa trên mốc đó.
Nhưng nó vẫn chưa bắt đầu.
Yêu cầu đó vẫn phải được thông qua theo epoch và đến được một mốc kiểm tra (checkpoint) của Bitcoin trước khi 300 xác nhận thậm chí còn bắt đầu. Đến lúc tôi nhận ra điều đó, BABY vẫn bị khóa và vị trí đã có ít “khoảng trống” hơn so với những gì tôi đã lên kế hoạch.
Chi tiết trên màn hình quan trọng không phải là yêu cầu đã được chấp nhận. Mà là số lượng xác nhận Bitcoin vẫn chưa bắt đầu.
Tôi cần có BABY làm tài sản thế chấp trước mức $0.01188.
Thế nhưng nó bị kẹt trong hàng chờ thoát (exit queue) trong khi rủi ro thanh lý cứ ngày càng tiến gần.
#BABY $BABY @BabylonLabs_io
Tôi nghĩ “được chấp nhận” nghĩa là thời gian chờ đã bắt đầu. Vì vậy tôi đã đếm tiếp từ lúc bấm và lên kế hoạch cho việc di chuyển tài sản thế chấp dựa trên mốc đó.
Nhưng nó vẫn chưa bắt đầu.
Yêu cầu đó vẫn phải được thông qua theo epoch và đến được một mốc kiểm tra (checkpoint) của Bitcoin trước khi 300 xác nhận thậm chí còn bắt đầu. Đến lúc tôi nhận ra điều đó, BABY vẫn bị khóa và vị trí đã có ít “khoảng trống” hơn so với những gì tôi đã lên kế hoạch.
Chi tiết trên màn hình quan trọng không phải là yêu cầu đã được chấp nhận. Mà là số lượng xác nhận Bitcoin vẫn chưa bắt đầu.
Tôi cần có BABY làm tài sản thế chấp trước mức $0.01188.
Thế nhưng nó bị kẹt trong hàng chờ thoát (exit queue) trong khi rủi ro thanh lý cứ ngày càng tiến gần.
#BABY $BABY @BabylonLabs_io
Tôi tìm thấy một khoản đặt cược BTC có thể xác nhận trên Bitcoin và vẫn trở nên không sử dụng được ở Babylon.
Cái bẫy nằm ở thời điểm tham số. Babylon phiên bản hóa các quy tắc đặt cược BTC theo btc_activation_height. Ở luồng trước khi đặt cược, tôi phải xây dựng dựa trên bộ tham số mà client light Bitcoin riêng của Babylon nhìn thấy khi tôi đăng ký, chứ không phải bất cứ thứ gì trông có vẻ hiện tại khi Bitcoin sau đó khai thác giao dịch. Phiên bản được chọn này sẽ cố định các khóa covenant và quorum, cùng với các điều kiện unbonding mà Babylon sẽ xác minh.
Lỡ tra cứu đó thì giao dịch có thể làm đúng như những gì tôi đã ký. Bitcoin chấp nhận đầu ra. Thợ đào được trả tiền. Các xác nhận cứ thế tích lũy. Rồi Babylon không thể xác minh gói đặt cược vì script được xây cho một bộ quy tắc sai.
Với một nhà xây dựng ví, điều đó tạo ra một kết quả thành công giả dã man. BTC của người dùng đã rời khỏi số dư có thể chi tiêu và nằm trong một đầu ra đặt cược ràng buộc theo thời gian, nhưng vị thế đó không có quyền biểu quyết và không nhận được gì. Một lần thử lại thông thường không thể sửa một script đã được cam kết trên Bitcoin.
Tôi sẽ đặt phiên bản tham số và activation height lên màn hình ký, rồi chặn phát sóng (broadcast) bất cứ khi nào chế độ xem của light-client Babylon của tôi bị lỗi thời. Che việc tra cứu đó sau một xác nhận màu xanh là cách một tích hợp biến Bitcoin hợp lệ thành vốn đặt cược bị mắc kẹt.
#baby $BABY @BabylonLabs_io
Cái bẫy nằm ở thời điểm tham số. Babylon phiên bản hóa các quy tắc đặt cược BTC theo btc_activation_height. Ở luồng trước khi đặt cược, tôi phải xây dựng dựa trên bộ tham số mà client light Bitcoin riêng của Babylon nhìn thấy khi tôi đăng ký, chứ không phải bất cứ thứ gì trông có vẻ hiện tại khi Bitcoin sau đó khai thác giao dịch. Phiên bản được chọn này sẽ cố định các khóa covenant và quorum, cùng với các điều kiện unbonding mà Babylon sẽ xác minh.
Lỡ tra cứu đó thì giao dịch có thể làm đúng như những gì tôi đã ký. Bitcoin chấp nhận đầu ra. Thợ đào được trả tiền. Các xác nhận cứ thế tích lũy. Rồi Babylon không thể xác minh gói đặt cược vì script được xây cho một bộ quy tắc sai.
Với một nhà xây dựng ví, điều đó tạo ra một kết quả thành công giả dã man. BTC của người dùng đã rời khỏi số dư có thể chi tiêu và nằm trong một đầu ra đặt cược ràng buộc theo thời gian, nhưng vị thế đó không có quyền biểu quyết và không nhận được gì. Một lần thử lại thông thường không thể sửa một script đã được cam kết trên Bitcoin.
Tôi sẽ đặt phiên bản tham số và activation height lên màn hình ký, rồi chặn phát sóng (broadcast) bất cứ khi nào chế độ xem của light-client Babylon của tôi bị lỗi thời. Che việc tra cứu đó sau một xác nhận màu xanh là cách một tích hợp biến Bitcoin hợp lệ thành vốn đặt cược bị mắc kẹt.
#baby $BABY @BabylonLabs_io
Tôi phát hiện ra một nhà cung cấp tính năng cuối cùng (finality) của Babylon có thể vượt qua bài kiểm tra sức khỏe trong khi mọi yêu cầu ký quan trọng đã chết từ trước.
Điểm mù nằm giữa fpd và eotsd. Babylon cho phép Ping đi qua mà không cần HMAC, nên một công cụ giám sát có thể tiếp tục hiển thị trình quản lý EOTS là có thể truy cập được. Nhưng SignEOTS, SignSchnorrSig và CreateRandomnessPairList đều cần khóa dùng chung. Chỉ cần có một sự không khớp giữa fpd.conf và eotsd.conf—thậm chí là một khoảng trắng thừa—thì lời gọi vô hại sẽ được đánh dấu xanh, trong khi các lời gọi cho môi trường production lại bị từ chối.
Điều đó có nghĩa là tôi có thể chạy đồng thời hai daemon, một node Babylon Genesis đã được đồng bộ, mở kết nối RPC, và vẫn không có đầu ra finality nào sử dụng được. Nhà cung cấp không thất bại ồn ào khi khởi động. Nó thất bại khi fpd hỏi eotsd để lấy chữ ký hoặc tính ngẫu nhiên cần thiết cho chiều cao (height) tiếp theo.
Tôi sẽ không chỉ cảnh báo dựa trên Ping. Tôi sẽ kiểm tra một luồng ký đã được xác thực và theo dõi yêu cầu EOTS cuối cùng thành công. Nếu không, bảng điều khiển chỉ chứng minh rằng cánh cửa tồn tại, chứ không chứng minh rằng chìa khóa vẫn mở được.
Đối với một nhà vận hành Babylon, kết nối “xanh” có thể che giấu một nhà cung cấp đã ngừng bỏ phiếu (voting).
#baby $BABY @BabylonLabs_io
Điểm mù nằm giữa fpd và eotsd. Babylon cho phép Ping đi qua mà không cần HMAC, nên một công cụ giám sát có thể tiếp tục hiển thị trình quản lý EOTS là có thể truy cập được. Nhưng SignEOTS, SignSchnorrSig và CreateRandomnessPairList đều cần khóa dùng chung. Chỉ cần có một sự không khớp giữa fpd.conf và eotsd.conf—thậm chí là một khoảng trắng thừa—thì lời gọi vô hại sẽ được đánh dấu xanh, trong khi các lời gọi cho môi trường production lại bị từ chối.
Điều đó có nghĩa là tôi có thể chạy đồng thời hai daemon, một node Babylon Genesis đã được đồng bộ, mở kết nối RPC, và vẫn không có đầu ra finality nào sử dụng được. Nhà cung cấp không thất bại ồn ào khi khởi động. Nó thất bại khi fpd hỏi eotsd để lấy chữ ký hoặc tính ngẫu nhiên cần thiết cho chiều cao (height) tiếp theo.
Tôi sẽ không chỉ cảnh báo dựa trên Ping. Tôi sẽ kiểm tra một luồng ký đã được xác thực và theo dõi yêu cầu EOTS cuối cùng thành công. Nếu không, bảng điều khiển chỉ chứng minh rằng cánh cửa tồn tại, chứ không chứng minh rằng chìa khóa vẫn mở được.
Đối với một nhà vận hành Babylon, kết nối “xanh” có thể che giấu một nhà cung cấp đã ngừng bỏ phiếu (voting).
#baby $BABY @BabylonLabs_io
Đăng nhập để khám phá thêm nội dung