TL;DR: Thời hạn di chuyển TAP của Đồ thị là ngày 3 tháng 12 năm 2024 và khoảng 34% người lập chỉ mục đã được nâng cấp, chiếm 81,6% khối lượng truy vấn. Cuộc thảo luận Hỏi & Đáp tập trung vào cài đặt cấu hình của TAP, đặc biệt liên quan đến các yêu cầu RAV (Phiếu tổng hợp biên nhận) và quản lý các khoản phí không tổng hợp, với đề xuất bắt đầu với các giá trị mặc định và điều chỉnh dựa trên khối lượng truy vấn.
Xin chào mọi người, chào mừng bạn đến với biên bản cuộc họp Giờ làm việc của Người lập chỉ mục, Phiên 184!
Link video: https://youtu.be/w0LZkVJemPY
Xem podcast GRTiQ với Jeroen Develter, COO của Persistence Labs. Hành trình web3 của Jeroen bắt đầu trong thế giới tư vấn, tài chính truyền thống và nhảy vào thế giới tiền điện tử và blockchain.
Cập nhật mới nhất cho các kho quan trọng
- Geth phiên bản mới v1.4.12:
- Ngày: 2024-11-19 13:53:28 UTC
- Bản phát hành này loại bỏ không gian tên RPC cá nhân không được dùng nữa và lệnh –unlock, biểu thị những thay đổi đáng kể đối với việc quản lý khóa. Nó cũng bao gồm các tối ưu hóa, cải tiến cơ sở dữ liệu và sửa nhiều lỗi khác nhau cũng như những thay đổi đáng kể đối với cấu hình trình theo dõi.
- Chỉ báo khẩn cấp: màu vàng
- Lý do khẩn cấp: Những thay đổi về quản lý khóa yêu cầu người dùng phải điều chỉnh.
- Reth phiên bản mới v1.1.2
- Ngày: 2024-11-19 16:27:10 UTC
- Bản phát hành này bao gồm các cải tiến về hiệu suất, sửa lỗi và sự chuẩn bị quan trọng cho đợt hard fork mới. Những thay đổi này đặc biệt tối ưu hóa việc thu thập công việc có tải trọng và giải quyết các yêu cầu giao dịch đang chờ xử lý, khiến người dùng OP-reth phải luôn cập nhật.
- Chỉ báo khẩn cấp: màu đỏ
- Lý do khẩn cấp: Chuẩn bị hard fork cho người dùng OP-reth.
- sfeth/fireeth: phiên bản mới v2.8.0:
- Ngày: 2024-11-14 14:55:01 UTC
- CombineFilter tích hợp kiểm tra an toàn không để tăng cường sự ổn định trong quá trình xử lý giao dịch. Ngoài ra, các bản cập nhật cho luồng con và đo sáng bao gồm các cải tiến về chức năng đo sáng.
- Chỉ báo khẩn cấp: màu vàng
- Lý do khẩn cấp: Cải thiện sự ổn định, không phải là mối đe dọa trước mắt.
- Tuyết lở: Phiên bản mới v1.11.13:
- Ngày: 2024-11-18 22:24:03 UTC
- Bản phát hành này giới thiệu các API mới cho nền tảng, cũng như các bản sửa lỗi cho các cải tiến về khả năng tương thích và khởi tạo số liệu RPCChainVM. Nhà điều hành nên cập nhật phiên bản plug-in mới nhất để nâng cao khả năng tương thích và ổn định.
- Chỉ báo khẩn cấp: màu vàng
- Lý do khẩn cấp: Các bản sửa lỗi quan trọng và tính năng mới cần được chú ý ngay lập tức.
- Dịch vụ và đại lý lập chỉ mục (TS): Phiên bản mới v0.21.8:
- Ngày: 2024-11-18 19:23:13 UTC
- Bản phát hành này bao gồm một số cập nhật nhỏ, cải thiện giao diện người dùng bằng cách hạ thấp các thông báo xung đột về độ cao đồ thị con và sửa tham số khoảng thời gian bỏ phiếu trong tác nhân chỉ mục. Không tìm thấy thay đổi quan trọng nào ảnh hưởng đến hiệu suất hoặc bảo mật hệ thống.
- Chỉ báo khẩn cấp: màu xanh lá cây
- Lý do khẩn cấp: thay đổi ít tác động, không có vấn đề nghiêm trọng.
- Dịch vụ lập chỉ mục và Tác nhân nhấp chuột (RS): Phiên bản mới trình lập chỉ mục-tap-agent-v1.7.3:
- Ngày: 2024-11-13 19:04:13 UTC
- Phiên bản 1.7.3 giải quyết lỗi bằng cách xóa các bước kiểm tra bộ điều hợp được quản lý, lỗi này có thể ảnh hưởng đến quá trình xử lý giao dịch. Tất cả các nhà khai thác nên xem xét thay đổi này để đảm bảo chức năng được thông suốt.
- Chỉ báo khẩn cấp: màu vàng
- Lý do khẩn cấp: Bản sửa lỗi quan trọng, không nghiêm trọng nhưng nên cập nhật càng sớm càng tốt.
Cập nhật mới nhất về những thay đổi quan trọng đối với giao thức
- Trọng tài nâng cao trong The Graph: Ra mắt nhóm làm việc, mở rộng ủy ban trọng tài và cập nhật quy trình
- Nhóm công tác trọng tài mới sẽ tạm thời đảm nhận nhiệm vụ của Nhà phân tích trọng tài cho đến khi có nhà phân tích mới tham gia.
- Việc mở rộng hội đồng trọng tài củng cố cam kết của The Graph trong việc duy trì các tiêu chuẩn cao trong trọng tài.
- Quá trình phân xử trọng tài đang được xem xét tích cực để xác định các lĩnh vực cần cải thiện.
- Xem bài đăng trên diễn đàn để biết Câu hỏi thường gặp và tài liệu tham khảo.
- Yêu cầu thông tin liên quan đến tranh chấp #GDR-19
- Tranh chấp này liên quan đến GDR-18 vì chính người lập chỉ mục đã lặp lại hành vi dẫn đến việc chém trước đó.
- Chung: Sử dụng tài khoản bảo mật hardhat cho các chuỗi không phải cục bộ #1070 (mở)
- Chung: Bump phiên bản Ignition lên 0.15.7 #1069 (Mở)
- Khắc phục: Đã thêm các tham số bị thiếu vào tập lệnh triển khai và giảm số lần chạy SubgraphService xuống 50 lần #1062 (Mở)
Cuộc thảo luận hôm nay là phần Hỏi & Đáp về di chuyển TAP với Ana từ GraphOps và Gustavo từ Semiotic Labs. TAP là một hệ thống thanh toán vi mô mới để truy vấn Biểu đồ.
🚨 Người lập chỉ mục cần di chuyển sang TAP trước ngày 3 tháng 12 năm 2024.
Phiên này được hướng dẫn bởi các ghi chú Hỏi & Đáp về di chuyển IOH TAP của Ana, đã được sao chép vào phần này cùng với một số thông tin cơ bản từ cuộc thảo luận. Bình luận đã được chỉnh sửa nhẹ
Ana |GraphOps: Hãy bắt đầu với TAP là gì?
Tổng quan về TAP (Giao thức tổng hợp dòng thời gian):
- Thay thế hệ thống thanh toán Scalar cũ.
- Nó có các tính năng chính như thanh toán vi mô hiệu quả, giảm giao dịch trên chuỗi và kiểm soát người lập chỉ mục đối với các khoản thu.
- Kích hoạt các cổng phi tập trung bằng cách cho phép người lập chỉ mục chấp nhận các truy vấn từ nhiều cổng.
Người lập chỉ mục cần làm gì?
- Cập nhật ngăn xếp bộ chỉ mục để chạy tác nhân chỉ mục (phiên bản 0.21.4 trở lên), thay thế dịch vụ chỉ mục để chạy phiên bản Rust và thêm tác nhân chỉ mục-tap-agent thành phần mới.
- Repo lập chỉ mục (indexer-agent)
- Cơ sở mã của trình lập chỉ mục-rs (dịch vụ lập chỉ mục và tác nhân lập chỉ mục-tap)
- tài nguyên:
- Nếu sử dụng Kubernetes, hãy sử dụng launchpad-charts/graph-network-indexer
- Nếu sử dụng Docker Compose, hãy sử dụng ngăn xếp StakeSquid
- Hướng dẫn di chuyển TAP
Mickey |The Graph |E&N: Điều gì sẽ xảy ra nếu người lập chỉ mục bỏ lỡ thời hạn? Cổng sẽ không định tuyến bất kỳ truy vấn mới nào tới chúng cho đến khi chúng được nâng cấp hoặc...?
- Gustavo |Semiotic Labs: Cổng hiện cung cấp biên lai cho Scalar và TAP. Khi chúng tôi đạt đến thời hạn, cổng sẽ chỉ hỗ trợ biên lai TAP. Nếu phiên bản của bạn thấp hơn 1.0, bạn sẽ không nhận được truy vấn nữa.
- Ana: Cảm ơn, điều đó có ý nghĩa. Vì vậy, nếu bạn muốn tiếp tục nhận được truy vấn, bạn cần phải di chuyển.
Mickey |The Graph |E&N: Có cách nào để biết bao nhiêu phần trăm người lập chỉ mục đã được chuyển sang người lập chỉ mục-rs/tap không?
- Ana: Một cách để biết liệu người lập chỉ mục đã được di chuyển sang TAP hay chưa là liệu họ có huy hiệu được gắn nhãn TAP READY trên tệp cấu hình trình lập chỉ mục của họ trong GraphSeer hay không.
- Gustavo: Tại Semiotic, chúng tôi đang theo dõi con số này một cách chặt chẽ, kiểm tra xem liệu trình lập chỉ mục có đang chạy phiên bản cao hơn 1.0 hay không. Trong số 88 người lập chỉ mục mà chúng tôi theo dõi, 30 người đang chạy phiên bản lập chỉ mục 1.0 trở lên, chiếm khoảng 34% số người lập chỉ mục.
- Chúng tôi cũng đang theo dõi số lượng truy vấn được phân phát trong tháng qua cho mỗi truy vấn, vì vậy hiện tại chúng tôi có 81,6% truy vấn chạy qua TAP.
- Ana: Tôi nghĩ điều bạn đang nói là trình lập chỉ mục có lượng truy vấn cao nhất đã được nâng cấp.
- Gustavo: Vâng. Trong số 10 công ty lập chỉ mục hàng đầu, 9 công ty đã được nâng cấp. Trên thực tế, trong số 14 bộ chỉ mục đầu tiên, 13 bộ đã được nâng cấp.
Mickey |The Graph |E&N: Ấn tượng của tôi là rất nhiều người lập chỉ mục đang gặp vấn đề khi nâng cấp - ấn tượng đó có đúng không và nếu đúng thì thời hạn ngày 3 tháng 12 có thực tế để mọi người ở đó đều được nâng cấp trước đó không? (không có bóng, chỉ tò mò liệu điều này có đủ ổn định không)
- Gustavo: Tôi nghĩ chúng tôi đang đi đúng hướng để [di chuyển] hầu hết các truy vấn. Việc di chuyển 100% số người lập chỉ mục trước thời hạn ngày 3 tháng 12 hơi khó khăn, nhưng tôi nghĩ chúng ta có thể dễ dàng đạt được 95%. Chúng tôi ở đây để hỗ trợ bạn để chúng tôi có thể cố gắng đạt được 100%.
Mickey |The Graph |E&N: Tại sao lại là 88 [người lập chỉ mục]? Đây có phải chỉ là những cái thực sự phục vụ truy vấn?
- Gustavo: Chúng tôi sử dụng biểu đồ con Chất lượng dịch vụ (QoS) để kiểm tra tất cả những người lập chỉ mục đang hoạt động, vì vậy về cơ bản nếu họ phân phát truy vấn trong tháng trước thì họ sẽ xuất hiện trong danh sách 88. Chúng tôi chủ yếu quan tâm đến các truy vấn và chúng tôi hài lòng nếu người lập chỉ mục phục vụ truy vấn đang sử dụng phiên bản mới nhất.
paka |E&N: Tôi cũng tin tưởng rằng hầu hết lưu lượng truy vấn sẽ được đưa đến TAP.
Mickey |The Graph |E&N: Được rồi, hiểu rồi! Chiến lược tốt.
Mickey |The Graph |E&N: Bạn có liên hệ riêng với những người tụt hậu đã đưa ra yêu cầu nhưng chưa nâng cấp không?
- Gustavo: Chúng tôi đang trong quá trình liên hệ với những người lập chỉ mục mà chúng tôi đã liên hệ. Chúng tôi có một danh sách và chúng tôi đang liên hệ với từng người, bắt đầu từ danh sách lớn nhất. Hiện tại, 2 cái lớn nhất vẫn chưa được nâng cấp là Update Indexer [Edge & Node] và Pinax. Chúng tôi đang hợp tác chặt chẽ với Edge và Node để họ có thể hỗ trợ nâng cấp lên các phiên bản ngoài 1.0. Miễn là chúng tôi có liên hệ với người lập chỉ mục đó, chúng tôi sẽ làm việc từng truy vấn từ các truy vấn có số lượng truy vấn cao nhất được phân phát đến các truy vấn có số lượng ít nhất.
Ana: Người lập chỉ mục có thể gắn cờ bất kỳ người lập chỉ mục nào đã di chuyển để được hỗ trợ. Nếu bạn có bất kỳ câu hỏi nào, xin vui lòng liên hệ với chúng tôi.
Gustavo | Semiotic Labs: Nếu ai có bất kỳ câu hỏi nào, tôi sẽ trả lời họ trong các kênh 📁︱người lập chỉ mục và 📁︱người lập chỉ mục -phần mềm trong The Graph Discord.
- Các khoản phí chưa được tổng hợp và yêu cầu RAV:
- Vấn đề: Người lập chỉ mục có thể thấy các khoản phí chưa tổng hợp của họ không thay đổi, đặc biệt nếu rav_request_trigger_value được đặt quá thấp.
- Giải thích: rav_request_trigger_value xác định thời điểm người lập chỉ mục yêu cầu Phiếu tổng hợp biên nhận (RAV) từ người gửi (bạn có thể coi người gửi là một cổng). Nếu giá trị này quá thấp, kích hoạt có thể không được đáp ứng đủ thường xuyên, khiến điện tích tích tụ mà không được cuộn lại.
- Giải pháp: Cập nhật rav_request_trigger_value của bạn, được tính bằng max_amount_willing_to_lose_grt / trigger_value_divisor.
Ana: Có một bảng điều khiển; tôi đặt nó ở đây. Trong bảng chưa tổng hợp, bạn có thể thấy giá trị kích hoạt. Trong trường hợp của tôi, giá trị kích hoạt RAV là 3. Cách thức hoạt động là khi nhận được biên lai mới, giá trị của nó sẽ được cộng vào chi phí chưa tổng hợp và hệ thống liên tục kiểm tra xem tổng chi phí chưa tổng hợp có vượt quá giá trị kích hoạt hay không.
Khi điều kiện kích hoạt được đáp ứng, yêu cầu RAV được tạo bằng cách kiểm tra bộ đệm dấu thời gian để xác định khoảng thời gian lùi lại mà biên nhận sẽ được coi là một biên nhận và nó sẽ giới hạn số lượng biên nhận dựa trên giới hạn biên nhận yêu cầu RAV.
Nếu chúng ta xem nhanh cấu hình, có một số điều quan trọng ở đây:
- max_amount_willing_to_lose_GRT
- trigger_value_divisor
Hai cái này xác định giá trị kích hoạt.
- timestamp_buffer_secs, tức là thời điểm biên nhận được xem xét
- max_receipts_per_request, do đó RAV có thể chứa tối đa 10000 biên nhận
Nếu bất kỳ biên nhận nào không hợp lệ, chúng sẽ được lưu trữ riêng trong bảng biên nhận Scaler TAP không hợp lệ trong cơ sở dữ liệu siêu dữ liệu của bộ chỉ mục. Khi max_receipt_value_GRT cao hơn giá trị này thì biên nhận không hợp lệ.
Cấu hình: maximal-config-example-toml
Gustavo: Tôi chỉ muốn nói về những gì đang diễn ra ở đây và tại sao chúng ta có nhiều cấu hình. Đối với hầu hết người lập chỉ mục, những cấu hình này sẽ không thành vấn đề vì chúng không có khối lượng truy vấn lớn.
Nếu bạn có quá nhiều phân bổ mỗi giây hoặc quá nhiều truy vấn, điều này có thể gặp một chút khó khăn, đó là lý do tại sao bạn cần cập nhật và định cấu hình những thứ này. Nói chung tôi khuyên bạn nên thử các giá trị mặc định trước và xem. Các giá trị mặc định hiện tại là:
- max_amount_willing_to_lose_GRT = 20
- trigger_value_divisor = 10
- Điều này có nghĩa là mỗi khi tổng số tiền thu được chưa tóm tắt của bạn (còn được gọi là khoản phí chưa tóm tắt) đạt đến 2 GRT, chúng tôi sẽ cố gắng cộng chúng lại. Tuy nhiên, nếu giá trị luôn lớn hơn 2 thì bạn cần thay đổi các giá trị này.
- Cố gắng giữ max_amount_willing_to_lose_GRT ở mức thấp nhất có thể. Tuy nhiên, nếu yêu cầu RAV không thành công và lúc đó bạn nhận được rất nhiều biên nhận vì bạn là người lập chỉ mục lớn, bạn sẽ chặn người gửi rất nhanh.
- dấu thời gian_buffer_secs = 60
- request_timeout_secs = 5
- max_receipts_per_request = 10000
15-20 người lập chỉ mục đầu tiên cần cập nhật các giá trị này.
Pierre | Chain-Insights.io: Giá trị lý tưởng của tôi là gì? Mặc định vẫn tốt cho tôi? Tôi dường như không có yêu cầu RAV.
15-20 người lập chỉ mục đầu tiên cần cập nhật các giá trị này.
Pierre | Chain-Insights.io: Giá trị lý tưởng của tôi là gì? Mặc định vẫn tốt cho tôi? Tôi dường như không có yêu cầu RAV.
Gustavo: Để tôi kiểm tra... Giá trị kích hoạt Tổng Chi phí chưa tổng hợp. Vì vậy, đầu tiên một vài cập nhật. Bạn đang sử dụng phiên bản nào?
Pierre: Phiên bản mới nhất.
Gustavo: Thông thường khi bạn đạt tới RAV kích hoạt, nó sẽ cố gắng tạo yêu cầu RAV. Nếu điều này không xảy ra, chúng ta cần phải điều tra.
Pierre | Chain-Insights.io: Không dành cho tôi:
tap: max_amount_willing_to_lose_grt: 20 tap.rav_request: trigger_value_divisor: 2 timestamp_buffer_secs: 60 request_timeout_secs: 5 max_receipts_per_request: 10000
Gustavo: Vậy giá trị kích hoạt của bạn là khoảng 10 phải không?
Pierre đã đăng: Có, 20/2
Gustavo: Vì vậy, bạn chỉ kích hoạt yêu cầu RAV khi bạn đạt được 10 GRT hoặc 10000 biên lai cho một phân bổ nhất định. Do khối lượng truy vấn của bạn, tôi khuyên bạn nên sử dụng khoảng 0,1 hoặc:
max_amount_willing_to_lose_grt: 1 trigger_value_divisor: 10 max_receipts_per_request: 1000
Pierre đã đăng: Được rồi, cảm ơn bạn.
Gustavo: Nếu không có nhiều truy vấn mỗi giây, bạn cần có nhiều yêu cầu RAV hơn hoặc có giá trị kích hoạt lớn hơn.
Tất cả phụ thuộc vào số lượng phân bổ bạn mở và số lượng truy vấn mỗi giây bạn nhận được cũng như số lượng truy vấn mỗi giây trên mỗi phân bổ và bất kỳ đợt phân bổ nào bạn có.
Trong TAP, sau khi tổng hợp tại một thời điểm, các biên nhận có dấu thời gian trước thời điểm đó sẽ không hoạt động. Chúng được coi là không hợp lệ, vì vậy đó là lý do tại sao chúng tôi có bộ đệm này. Chúng tôi chỉ chấp nhận biên lai sau 60 giây. Điều này là do việc đồng bộ hóa đồng hồ giữa các máy tính khác nhau rất khó khăn. Cổng sẽ gửi cho bạn biên nhận và xác định dấu thời gian, có thể là 5 giây trước hoặc sau đồng hồ của bạn.
Chúng tôi đặt các giá trị mặc định ở khoảng giữa, tức là 1-2 truy vấn mỗi giây và 1 yêu cầu RAV cứ sau 15 phút. Tuy nhiên, nếu bạn có ít hơn dung lượng bộ nhớ này, bạn có thể cần cập nhật lên mức tối đa_amount_willing_to_lose_grt thấp hơn. Nếu vượt quá con số này, bạn có thể cần phải cập nhật thêm.
Gemma | LunaNova: Đây là những giá trị trên mỗi lần phân bổ hay trên tất cả các lần phân bổ?
calinah | GraphOps: mỗi bài tập
Pierre | Chain-Insights.io: Sau khi cập nhật lên các phiên bản sau:
Gemma | LunaNova: Đây là những giá trị trên mỗi lần phân bổ hay trên tất cả các lần phân bổ?
calinah | GraphOps: mỗi bài tập
Pierre | Chain-Insights.io: Sau khi cập nhật lên các phiên bản sau:
calinah |GraphOps: Tuyệt vời, tỷ lệ chấp nhận của bạn đã được cải thiện.
Gustavo: Ừ, tốt đấy. Vì vậy, điều bạn muốn làm cho bảng điều khiển là khoản phí chưa tổng hợp phải luôn ở mức 0,1, do đó, mỗi khi bạn có một yêu cầu RAV, nó sẽ giảm đi một chút và sau 15 phút, bạn có đủ biên lai để kích hoạt một yêu cầu RAV khác.
Josh Kauffman |StreamingFast.io: Có ai có thể chia sẻ những gì họ đặt cho những giá trị này không?
Marc-André |Ellipfra: Để tham khảo, tôi đã sử dụng các giá trị này cho chiến dịch của mình. Tôi không đặc biệt khuyên dùng chúng vì chúng được đặt ít nhiều ngẫu nhiên. max_willing_to_lose rất cao để tránh bị từ chối cổng quá thường xuyên, tôi dự định sẽ hạ nó xuống vào một lúc nào đó:
max_amount_willing_to_lose_grt = "1000.0" [tap.rav_request] timestamp_buffer_secs = 30 trigger_value_divisor = 50 request_timeout_secs = 20 max_receipts_per_request = 2000
- Vấn đề từ chối người gửi:
- Người gửi không được liệt kê trong tap.sender_aggregator_endpoints.
- Số dư ký quỹ của người gửi không đủ để trang trải các khoản phí chưa thanh toán.
- Phí chưa tổng hợp vượt quá giới hạn max_fee_per_sender.
- Sự cố: Người lập chỉ mục có thể gặp phải sự từ chối của người gửi, dẫn đến gián đoạn quá trình xử lý truy vấn và doanh thu.
- Lý do từ chối: Có ba lý do chính khiến người gửi bị từ chối:
- Giải pháp: Giải pháp cụ thể cho từng lý do từ chối:
- Xác minh rằng người gửi được định cấu hình chính xác trong phần tap.sender_aggregator_endpoints.
- Điều tra các vấn đề tiềm ẩn với quỹ ký quỹ và đảm bảo số dư đầy đủ.
- Nếu các khoản phí chưa tổng hợp thường xuyên đạt đến giới hạn, hãy xem lại và có thể điều chỉnh cài đặt max_amount_willing_to_lose_grt.
- LƯU Ý: Tác nhân TAP của bộ chỉ mục sẽ luôn bắt đầu bằng tên sau:
2024-11-13T08:41:31.200776Z ERROR indexer_tap_agent::agent::sender_accounts_manager: There was an error while starting the sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490, denying it. Error: No sender_aggregator_endpoints found for sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490 at tap-agent/src/agent/sender_accounts_manager.rs:311 in ractor::actor::Actor with id: "0.0"
Đối với INDEXER_TAP__SENDER_AGGREGATOR_ENDPOINTS__ không có trong tap.sender_aggregator_endpoints hoặc thông qua các biến env
- lỗi điểm cuối thu thập-nhận-trên tác nhân chỉ mục:
- người lập chỉ mục-agent 上的 điểm cuối thu thập-biên nhận 错误:
{"level":40,"time":1731239677641,"pid":1,"hostname":"graph-network-indexer-agent-0","name":"IndexerAgent","msg":"The option '--collect-receipts-endpoint' is deprecated. Please use the option '--gateway-endpoint' to inform the Gateway base URL."}
Gustavo: Lý do bạn muốn từ chối người gửi là vì người gửi chưa thanh toán cho bạn nên họ không có đủ ký quỹ hoặc họ đang yêu cầu bạn một số tiền mà bạn sẵn sàng mất. Một điều khác có thể xảy ra là chúng tôi sử dụng biên nhận không hợp lệ cho việc này, vì vậy nếu số lượng biên nhận không hợp lệ bạn có là số lượng tối đa bạn sẵn sàng mất, bạn sẽ chặn người gửi vì điều đó.
Cập nhật nhanh về max_receipt_value_grt là điều này chỉ áp dụng cho dịch vụ đó. Để TAP được tin cậy ở mức tối thiểu, đây phải là các khoản thanh toán vi mô, vì vậy khi cổng gửi cho bạn biên nhận, đây là giá trị biên nhận tối đa mà họ sẽ chấp nhận mà không bị coi là biên nhận không hợp lệ.
Biên nhận không hợp lệ là biên nhận bạn nhận được, đưa ra yêu cầu và sau đó phát hiện ra rằng biên nhận không hợp lệ.
Ana: Đối với các biên nhận không hợp lệ, chúng sẽ có hiệu lực nếu có bất kỳ điều kiện nào thay đổi hay sẽ không cần thử lại sau khi biên nhận được đánh dấu là không hợp lệ?
Gustavo: Không thử lại. Bảng này chỉ được sử dụng để ghi nhật ký để bạn có thể truy cập cơ sở dữ liệu và xem điều gì đã xảy ra cũng như lý do tại sao việc nhận không thành công.
Ana: Điều đó có ý nghĩa. Ngoài ra, trên bảng điều khiển TAP, bạn có thể xem người gửi có bị chặn hay không.
- Lỗi yêu cầu RAV:
- Sự cố: Lỗi trong quá trình yêu cầu RAV có thể làm gián đoạn quá trình tổng hợp.
- Ví dụ về lỗi: Có vẻ như yêu cầu RAV không có biên nhận hợp lệ... Bạn có thể khắc phục lỗi này bằng cách tăng rav_request_trigger_value.
- Giải thích: Lỗi này cho biết rằng rav_request_trigger_value không đủ sẽ ngăn không cho biên nhận được đưa vào yêu cầu RAV.
- Giải pháp: Giải pháp được cung cấp trong thông báo lỗi – tăng rav_request_trigger_value.
- Phiên bản phần mềm: Sử dụng phiên bản phần mềm được yêu cầu cho tác nhân lập chỉ mục, dịch vụ lập chỉ mục và tác nhân nhấn.
- Hướng dẫn tập tin cấu hình:
- Cấu hình được chia sẻ: dịch vụ lập chỉ mục và tác nhân nhấn chia sẻ một tệp cấu hình TOML chung.
- Địa chỉ chuỗi khối và điểm cuối:
- Quan trọng: Sử dụng địa chỉ hợp đồng, điểm cuối cổng và ID chuỗi chính xác.
- Cấu hình cấp độ nhật ký: Để đặt biến môi trường RUST_LOG để ghi nhật ký thích hợp, hãy sử dụng RUST_LOG=indexer_tap_agent=debug,info.
- Trang tổng quan số liệu và Grafana:
- Điểm cuối số liệu: Tất cả các thành phần hiển thị số liệu trên cổng 7300 của Prometheus.
- Bảng điều khiển Grafana: indexer-rs/docs/dashboard.json
Pierre | Chain-Insights.io: Bây giờ, cho đến ngày 3 tháng 12, chỉ có một người gửi hoạt động?
# collect-receipts-endpoint: " " DEPRECATED # collect-receipts-endpoint: " " DEPRECATED gateway-endpoint: " " gateway-endpoint: " "
- Ana: Theo những gì tôi biết thì điều này là chính xác, vì vậy chỉ có các bộ truyền cạnh và nút là hoạt động và được mọi người sử dụng. GraphOps hy vọng sẽ có một số công cụ lập chỉ mục được thêm vào cổng của chúng tôi vào cuối tháng 12 đến đầu tháng 1.
Pierre: Điều này có tốt không hay tôi nên hoàn nguyên để kích hoạt điểm cuối thu-biên nhận?
Pierre: Điều này có tốt không hay tôi nên hoàn nguyên để kích hoạt điểm cuối thu-biên nhận?
- Ana: Sử dụng điểm cuối cổng là tuyệt vời. Về cơ bản, điều duy nhất bạn cần biết là bạn có thể chọn cờ CLI nào để sử dụng, nhưng dù thế nào bạn cũng sẽ thấy cùng một lỗi, đây là một lỗi khó hiểu nên bạn không cần phải làm gì ở đây.
Ana: Một số người lập chỉ mục đã di cư có nhận xét gì về những gì họ tìm thấy và muốn chia sẻ không?
- Marc-André |Ellipfra: Việc thiết lập và giám sát trang tổng quan là rất quan trọng. Nó ngày càng ổn định hơn sau mỗi lần phát hành, nhưng bạn không bao giờ biết được.
Gustavo: Nếu bạn có bất kỳ yêu cầu tính năng nào hoặc ý tưởng về cách định cấu hình nó tốt hơn, vui lòng nêu vấn đề trong kho lưu trữ của người lập chỉ mục.
Chúng tôi sẵn lòng xem xét mọi vấn đề và yêu cầu về tính năng để có thể làm cho hệ thống tốt hơn, công nghệ ổn định hơn và hy vọng đạt được mức độ tốt hơn. Cảm ơn bạn đã dành thời gian thảo luận chi tiết về TAP.
#blockchaindataindex#web3dataanalytics#TheGraph
Tất cả bình luận