Biểu đồ UNI burn trên Ethereum đang chậm gần một tuần so với Robinhood Chain

GHIM TẠIRobinhood Chain block 1 → 29.174.972 · Firepit 0x7a8f74c2585f84c781f951b7f2ff21337d5b630b · token bản Robinhood 0xf177d86a28b520e3e396e4f3b96cd8e72d7dabd8 · phía Ethereum: gateway 0x85001cc4867c5e1c22da4b79bb8852b9e2a06da0, block 25.671.175 → 25.690.453, 0 range rớt

ĐIỀU GÌ BÁC BỎ CLAIM NÀYQuét log Transfer của token bản Robinhood với from = Firepit và to = address(0) trên toàn dải block: ra khác 170 lượt hoặc khác 340.000 UNI thì claim này sai. Chiều thứ hai, độc lập: đếm Transfer với to = Firepit — vào phải bằng ra, cũng 170 lượt / 340.000. Phía Ethereum: đọc Transfer của UNI tới địa chỉ đốt, lọc địa chỉ gửi là gateway, trong dải block ghim — không ra đúng 22 dòng × 2.000 UNI thì con số 44.000 và tỉ lệ 12,9% sai. Hai đầu này đọc ở hai chain và hai thời điểm nên KHÔNG cộng lại được; cộng 296.000 với 44.000 để ra một lượng đã đốt là đọc sai claim.

GHIM TẠIEthereum block 25.690.453 · counterpartGateway() (selector 0x2db09c1c) trả 0xfd9b17206278c16ddaacf6ac8f05dbf97edcb31e · chiều ngược đọc trên Robinhood Chain block 29.174.972 · outbox 0xf0ce991ea4a0d2400a4ab49b20ae333f6dce3de9

ĐIỀU GÌ BÁC BỎ CLAIM NÀYBốn phép đọc độc lập chống claim này, chỉ cần một phép hỏng là phép gán chain mất giá trị và mọi câu gán 44.000 UNI cho Robinhood Chain phải rút: ⒜ gọi counterpartGateway() trên Ethereum — không trả 0xfd9b1720…b31e thì sai; ⒝ gọi cùng hàm đó trên địa chỉ vừa trả về bằng RPC công khai của Robinhood Chain — không trỏ ngược đúng 0x85001cc4… thì sai; ⒞ đọc một thông điệp L2ToL1Tx do Firepit phát — không ghi đích là 0x85001cc4… hoặc dữ liệu kèm theo không chứa đồng thời địa chỉ UNI trên Ethereum, địa chỉ đốt và số 2.000 × 10¹⁸ thì sai; ⒟ giao dịch đưa 2.000 UNI tới địa chỉ đốt gọi executeTransaction trên outbox — bridge() của outbox không trùng bridge đọc từ inbox() của gateway thì sai. Claim này KHÔNG nói Robinhood Chain là chain đóng góp lớn nhất: còn hai địa chỉ gửi chưa rõ thuộc chain nào, 20.000 và 4.000 UNI; nếu chúng cùng một chain và tổng vượt 44.000 thì thứ hạng ở cấp chain phải viết lại — nhưng 22 lượt và 44.000 UNI từ chính địa chỉ này vẫn đứng.

GHIM TẠIRobinhood Chain block 1 → 29.174.972 · L2ToL1Tx lọc theo đích là gateway 0xfd9b17206278c16ddaacf6ac8f05dbf97edcb31e: 312 thông điệp, 170 chứa đồng thời địa chỉ đốt + UNI trên Ethereum 0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 + số 2.000 × 10¹⁸

ĐIỀU GÌ BÁC BỎ CLAIM NÀYQuét lại L2ToL1Tx với đích là gateway trên toàn dải block, đếm số thông điệp chứa đủ ba dấu hiệu trên. Ra ít hơn 170 thì có lệnh rút không nhắm địa chỉ đốt và câu 'cả 170' sai. Ra nhiều hơn 170 thì phép ghép một-đổi-một với 170 lượt Firepit huỷ token sai. 142 thông điệp còn lại là rút thường của bên khác qua cùng gateway; nếu một thông điệp trong nhóm đó cũng mang đủ ba dấu hiệu thì phép đếm này lẫn và claim sai.

GHIM TẠIEthereum block 25.671.175 → 25.690.453 · giải mã trường l2Timestamp trong calldata executeTransaction của cả 22 lượt · hàng chờ thứ nhất (khoảng cách giữa hai lệnh liên tiếp trên Robinhood Chain): min 0 · trung vị 71 phút · max 1.682 phút

ĐIỀU GÌ BÁC BỎ CLAIM NÀYVới mỗi giao dịch đưa 2.000 UNI từ gateway tới địa chỉ đốt, đọc calldata của lời gọi executeTransaction và lấy trường l2Timestamp, rồi trừ khỏi timestamp block Ethereum của chính giao dịch đó. Ra ngoài khoảng 6,44–7,41 ngày ở bất kỳ lượt nào thì claim này sai. Phép ghép cặp này không giả định thứ tự — mỗi lượt tự khai thời điểm nó được phát ở đầu Robinhood — nên nếu ai đó ghép theo thứ tự trước-sau và ra số khác thì đó là phép ghép kia sai, không phải claim này. 🔴 Con số này là độ trễ từ LỆNH RÚT tới lúc thực thi, KHÔNG phải từ lúc phí phát sinh: đoạn phí nằm trong TokenJar trước khi thành UNI chưa được đo, nên tổng độ trễ thực tế chỉ có thể dài hơn.

GHIM TẠILệnh rút đầu: Robinhood block 20.678.587, 10:59:00Z ngày 27/07 · outbox 0xf0ce991ea4a0d2400a4ab49b20ae333f6dce3de9, 601 lượt OutBoxTransactionExecuted, index 0 → 796 · chưa thực thi quanh đó: 679 · 682–687 · 689 · 693 · 699 · cả 22 lượt đã về đều do 0x2cf8e5b175aa29c1fdf0e9fe572735c78eacce43 gọi

ĐIỀU GÌ BÁC BỎ CLAIM NÀYQuét log OutBoxTransactionExecuted của outbox trên toàn dải block và lập danh sách index đã thực thi. Nếu 679 có trong danh sách thì claim này sai. Nếu 678 hoặc 680 KHÔNG có trong danh sách thì phép so sánh 'bị nhảy qua' mất chỗ dựa và claim cũng sai. Chiều thứ hai: nếu mọi index chưa thực thi đều lớn hơn mọi index đã thực thi thì thứ tự là tuần tự và cách đọc của bài sai. 🔴 Chỗ bài chưa với tới: 127/601 lượt thực thi có đích là gateway này nhưng chỉ 22 đưa UNI tới địa chỉ đốt; 105 lượt còn lại đưa tài sản khác đi chỗ khác và bài không đo chúng — nên claim này nói về CÁCH chọn lượt, không nói gì về ý định của người chọn.