Hôm nay tôi đã xem cùng một phương trình được kiểm tra hai lần và suýt lướt qua luôn cả lý do vì sao.
Đọc một bản ghi chú về bảo mật của Dusk, công thức tính phí: giới hạn gas nhân với giá gas bằng phí tối đa. Việc này được thực thi hai lần: một lần khi vào mempool, lần nữa bên trong quá trình thực thi VM.
Lần đọc đầu tiên, tôi nghĩ đó chỉ là sự dư thừa. Thắt dây an toàn, chẳng có gì để đào sâu.
Nhưng không sống sót qua đoạn tiếp theo. Việc chỉ thực thi ở mempool là chưa đủ; một proposer độc hại không bắt buộc phải chỉ chèn phiên bản “đúng mempool” của các trường trong tx.
Đó mới là khoảng trống thực sự. Một giá trị được chứng minh hoặc được ký ở một phần của giao dịch không ràng buộc mọi lớp sau đó sẽ tiêu thụ nó. Ai đó có thể cam kết một khoản phí hợp lệ ngay từ đầu nhưng vẫn đưa một khoản phí khác cho phần thực thi, trừ khi bản thực thi độc lập từ chối việc tin vào lần kiểm tra trước đó đã xảy ra.
Ký và chứng minh phí tối đa, kiểm tra ở mempool, proposer tạo block mà không có nghĩa vụ phải giữ nguyên điều đó; VM sẽ thực thi logic hoàn phí dựa trên thứ thực sự đã đến.
Nó cứ quay lại vấn đề này: phần lớn sự tin cậy nằm ở việc proposer phải trung thực giữa các mốc kiểm tra—và chính giả định đó là lý do tồn tại lần kiểm tra thứ hai, bởi vì không thể dựa vào nó.
Không biết còn bao nhiêu trường khác trong chuỗi xử lý đó chỉ được kiểm tra ở một lớp.
Chuyện gì xảy ra với lần kiểm tra đó dưới tình trạng tắc nghẽn thực sự, khi các proposer bị áp lực phải dựng nhanh? 👍
#dusk $DUSK @Dusk
Đọc một bản ghi chú về bảo mật của Dusk, công thức tính phí: giới hạn gas nhân với giá gas bằng phí tối đa. Việc này được thực thi hai lần: một lần khi vào mempool, lần nữa bên trong quá trình thực thi VM.
Lần đọc đầu tiên, tôi nghĩ đó chỉ là sự dư thừa. Thắt dây an toàn, chẳng có gì để đào sâu.
Nhưng không sống sót qua đoạn tiếp theo. Việc chỉ thực thi ở mempool là chưa đủ; một proposer độc hại không bắt buộc phải chỉ chèn phiên bản “đúng mempool” của các trường trong tx.
Đó mới là khoảng trống thực sự. Một giá trị được chứng minh hoặc được ký ở một phần của giao dịch không ràng buộc mọi lớp sau đó sẽ tiêu thụ nó. Ai đó có thể cam kết một khoản phí hợp lệ ngay từ đầu nhưng vẫn đưa một khoản phí khác cho phần thực thi, trừ khi bản thực thi độc lập từ chối việc tin vào lần kiểm tra trước đó đã xảy ra.
Ký và chứng minh phí tối đa, kiểm tra ở mempool, proposer tạo block mà không có nghĩa vụ phải giữ nguyên điều đó; VM sẽ thực thi logic hoàn phí dựa trên thứ thực sự đã đến.
Nó cứ quay lại vấn đề này: phần lớn sự tin cậy nằm ở việc proposer phải trung thực giữa các mốc kiểm tra—và chính giả định đó là lý do tồn tại lần kiểm tra thứ hai, bởi vì không thể dựa vào nó.
Không biết còn bao nhiêu trường khác trong chuỗi xử lý đó chỉ được kiểm tra ở một lớp.
Chuyện gì xảy ra với lần kiểm tra đó dưới tình trạng tắc nghẽn thực sự, khi các proposer bị áp lực phải dựng nhanh? 👍
#dusk $DUSK @Dusk