TL;DR: Các điểm chính được trình bày trong cuộc thảo luận công khai về GIP-0081: Lập chỉ mục trả phí: - Động lực của đề xuất này là thiết kế một cách thân thiện với nhà phát triển để có được các đồ thị con được lập chỉ mục. -Thỏa thuận lập chỉ mục sẽ chỉ định các sơ đồ con được lập chỉ mục và giá cho mỗi đơn vị “công việc được lập chỉ mục đã thực hiện”. -Đề xuất bao gồm hai điều khoản để bảo vệ cổng: số tiền tối đa cho việc đồng bộ hóa ban đầu (chi phí cao hơn) và số tiền tối đa cho việc lập chỉ mục liên tục trên mỗi kỷ nguyên (chi phí thấp hơn). -Hệ thống sẽ được tự động hóa: người lập chỉ mục đặt ra các yêu cầu thanh toán tối thiểu cho các thực thể được lưu trữ trên mỗi chuỗi và các chỉ mục bị chặn, đồng thời giao thức lập chỉ mục sẽ tự động chấp nhận hoặc từ chối dựa trên các tham số này. -Nhóm Edge & Node đang tích cực thu hút ý kiến ​​đóng góp từ những người lập chỉ mục về chi phí vận hành để giúp xác định mức giá hợp lý.

Xin chào mọi người, chào mừng đế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 190!

Link video: https://youtu.be/imm3TFLCYkw

Xem podcast GRTiQ với người sáng lập Giao thức Boson Justin Banon. Boson Protocol đang xây dựng cơ sở hạ tầng kinh doanh phi tập trung và nhằm mục đích thay thế các trung gian thương mại điện tử truyền thống bằng giao thức trích xuất tối thiểu của web3.

Cập nhật mới nhất cho các kho quan trọng

Cập nhật mới nhất về những thay đổi quan trọng đối với giao thức

Cập nhật phát triển cốt lõi:

Matias, kỹ sư giao thức tại Edge & Node, có mặt ở đây để giới thiệu GIP-0081: Thanh toán được lập chỉ mục.

Một số nội dung sau đây được trích từ các slide thuyết trình, với các chi tiết bổ sung được thêm vào từ Matias. Một số bình luận đã được chỉnh sửa nhẹ.

Matias | Edge & Node: GIP-0081: Thanh toán theo chỉ số đã được đăng trên diễn đàn The Graph. Kiểm tra nó nếu bạn quan tâm.

GIP-0081 là một cơ chế được đề xuất theo đó các cổng có thể trả tiền cho người lập chỉ mục để phục vụ các sơ đồ con.

Tôi đã đề cập đến việc cung cấp một sơ đồ con và có cơ chế điều phối sự tương tác này. Vì vậy, từ quan điểm của nhà phát triển sprite, cách hiện tại để thực hiện việc này là gì?

Ngày nay, các nhà phát triển subplot cần:

Mặc dù cách tiếp cận tuyển chọn mà tôi vừa mô tả có một số nhược điểm nhưng không thể phủ nhận rằng nó là cơ sở cho toàn bộ thị trường lập chỉ mục như chúng ta biết ngày nay. Vì vậy, điều này sẽ không biến mất; đề xuất này không sửa đổi nó dưới bất kỳ hình thức nào. GIP-0081 bổ sung điều này theo cách sau đây mà tôi sẽ giải thích ngay bây giờ.

Việc củng cố toàn bộ cơ chế để cổng có thể trả tiền cho người lập chỉ mục để phục vụ sơ đồ con là cái mà chúng tôi gọi là giao thức lập chỉ mục. Phiên bản đơn giản nhất của nó có các mục sau:

Các điều khoản để bảo vệ cổng:

Đây là một thuật toán được thực hiện bởi cổng, một giao thức để chọn người lập chỉ mục nào nhận được đồ thị con nào. Có rất nhiều quyền lực trong động lực này, cổng có nhiều quyền kiểm soát đối với nó và đề xuất triển khai nó như một đặc điểm kỹ thuật như một phần của nó, mặc dù vì nó là một thành phần ngoài chuỗi nên nó không hoàn toàn là một phần của GIP.

IISA yêu cầu:

Cổng nằm ở giữa mối quan hệ giữa người sử dụng dữ liệu và người lập chỉ mục. Nó tổng hợp khối lượng truy vấn lớn và có cái nhìn duy nhất về hiệu suất trước đây của người lập chỉ mục và hiệu suất tổng thể hiện tại. Cổng có thể sử dụng các điểm dữ liệu này để chọn thiết bị lập chỉ mục một cách tối ưu.

Cho đến nay tôi đã mô tả phần on-chain của cơ chế thanh toán chỉ số, vì nó gắn liền với Graph Horizon, nó sẽ không ra mắt vào Q1, vì vậy chúng tôi đang nỗ lực phát triển một sản phẩm khả thi tối thiểu không yêu cầu triển khai hợp đồng mới Hoặc bất kỳ loại tương tác trực tuyến mới nào, vì vậy chúng tôi có thể thử nghiệm rất nhiều ý tưởng này.

Josh Kauffman | StreamingFast.io: Sẽ có hai mức cho mỗi kỷ nguyên: một cho giai đoạn đồng bộ hóa và một cho trạng thái ổn định? (Vì đồng bộ và chỉ truy vấn sẽ có chi phí dự kiến ​​​​khác nhau trên mỗi kỷ nguyên)

Josh giải thích: Câu hỏi của tôi là về chi phí tối đa cho mỗi kỷ nguyên có thể được đặt. Đối với tôi, có vẻ như chi phí của người lập chỉ mục sẽ rất cao trong giai đoạn đồng bộ hóa và thấp hơn nhiều ở trạng thái ổn định sau khi đồng bộ hóa. Vì vậy, rõ ràng giá trị tối đa trên mỗi kỷ nguyên phải được người tiêu dùng và cổng đặt ra để nó có thể xử lý giai đoạn đồng bộ hóa, nhưng để tránh bất kỳ sự lạm dụng nào, theo tôi, nên có giá trị tối đa thấp hơn trong giai đoạn trạng thái ổn định.

Matias: Giao thức lập chỉ mục có hai tham số riêng biệt, hai số tiền tối đa phải trả: một cho đồng bộ hóa ban đầu (trên slide tôi đã đề cập đến chỉ mục ban đầu), nhưng điều này được thực hiện từ lịch sử ban đầu trong sơ đồ con đến phần đầu chuỗi của tất cả công việc , đúng là con số này sẽ cao hơn nhiều so với mức tối đa duy trì trên mỗi kỷ nguyên. Điều này giải thích thực tế là, vâng, việc thực hiện đồng bộ hóa ban đầu đòi hỏi nhiều công việc hơn là theo kịp từng kỷ nguyên mới.

Có lẽ bây giờ sẽ là thời điểm tốt để giải quyết một số thách thức bằng cách tiếp cận cụ thể này. Ví dụ: nếu thỏa thuận bị hủy, điều đó có nghĩa là một thỏa thuận mới cần được cấp cho người lập chỉ mục khác, điều đó có nghĩa là cổng cũng như người sử dụng dữ liệu sẽ chịu trách nhiệm thanh toán cho một loạt chỉ mục ban đầu khác, trong đó, như bạn đã chỉ ra, có thể đắt hơn mỗi lần Lập chỉ mục liên tục cho các kỷ nguyên đắt hơn nhiều. Do đó, chúng tôi đang tìm cách cải thiện phiên bản đề xuất này nhằm giảm thiểu các lý do khiến thỏa thuận bị hủy bỏ và thậm chí có một số ý tưởng nhằm giảm thiểu chi phí lập chỉ mục ban đầu nếu thỏa thuận bị hủy bỏ. Chúng tôi nhận thức được những thiếu sót này và hy vọng chúng tôi có thể phát triển nó đủ nhanh để giải quyết chúng.

stake-machine.eth: Họ có đang kiếm được các mẹo dành cho người lập chỉ mục bên cạnh phần thưởng lập chỉ mục hiện tại không? Hoặc một sự thay thế hoàn toàn?

Matias: Nó chắc chắn không phải là một sự thay thế hoàn toàn, không hề. Nếu bạn đã lập chỉ mục cho biểu đồ con hoặc đã quản lý biểu đồ con, bạn có thể coi đây là thu nhập bổ sung bên cạnh phần thưởng lập chỉ mục. Nhưng có thể xảy ra trường hợp bạn bắt đầu thấy một số ô phụ không được quản lý mà thay vào đó được cung cấp các giao thức lập chỉ mục, trong trường hợp đó bạn sẽ không có phần thưởng lập chỉ mục cho ô phụ cụ thể đó, nhưng nếu bạn được cung cấp và chấp nhận rằng bạn sẽ nhận được thu nhập từ thỏa thuận lập chỉ mục. Nó thực sự phụ thuộc vào việc tình tiết phụ có được sắp xếp để bạn thu doanh thu từ hai nguồn hay chỉ một nguồn.

Matthew Darwin | Pinax: Tôi đoán cũng có một số loại thời gian chờ? Điều gì sẽ xảy ra nếu người lập chỉ mục đồng ý lập chỉ mục cho biểu đồ con, sau đó nghỉ 6 tháng và không bao giờ hoàn tất việc đồng bộ hóa.

Matias: Tất nhiên, tôi đã cố gắng làm cho nó đơn giản, cho đến hôm nay, thông số kỹ thuật đầy đủ thậm chí không phải là một phần của GIP, nhưng ý tưởng là chúng tôi đề cập đến những trường hợp này và chúng tôi phải cho phép nó áp dụng cho cả cổng và trình lập chỉ mục, vì vậy người lập chỉ mục cần được phép có đủ thời gian để thực hiện đồng bộ hóa ban đầu và không có nguy cơ mất bất kỳ khoản bồi thường nào cho công việc họ đã thực hiện cho đến thời điểm đó. Cổng cần phải chắc chắn rằng giao thức mà nó mở thực sự đang được phân phối; nếu không, nó cần tìm kiếm các giao thức khác. Tôi hy vọng kỳ nghỉ 6 tháng không diễn ra, nhưng nếu cổng không đạt hiệu quả như mong đợi, nó có thể hủy thỏa thuận.

PaulieB: Liệu các điểm dữ liệu hiệu suất cao này có được thêm vào Graph Explorer để có được sự minh bạch hoàn toàn không? Nó có trên GraphSeer, nhưng không chắc người tiêu dùng có sử dụng nó hay không.

Matias: Theo những gì tôi biết, chúng tôi đã xem xét khả năng tạo ra càng nhiều dữ liệu và thuật toán lựa chọn chỉ mục (IISA) mà cổng sử dụng để đưa ra các quyết định nguồn mở càng tốt. Tôi không chắc liệu nó sẽ được thêm vào Graph Explorer cụ thể hay một cách hoặc cơ chế nào khác. Câu trả lời ngắn gọn là, tôi mong đợi là có. Nếu điều này được điều khiển bởi một thuật toán thì ít nhất nó phải trong suốt đối với cổng Edge & Node.

NSun | Graphtronauts: Cũng là thông tin tuyệt vời dành cho người đại biểu. 💯 Giúp họ hỗ trợ người lập chỉ mục chất lượng.

Matthew Darwin |Pinax: Có lẽ, "công việc đã hoàn thành" có thể được báo cáo định kỳ trong giai đoạn lập chỉ mục ban đầu để ngăn chặn sự lạm dụng.

NSun | Graphtronauts: Cũng là thông tin tuyệt vời dành cho người đại biểu. 💯 Giúp họ hỗ trợ người lập chỉ mục chất lượng.

Matthew Darwin |Pinax: Có lẽ, "công việc đã hoàn thành" có thể được báo cáo định kỳ trong giai đoạn lập chỉ mục ban đầu để ngăn chặn sự lạm dụng.

Matias: Tôi nghĩ bạn đang nói về một tình huống mà việc lập chỉ mục ban đầu mất nhiều thời gian, vì vậy một số đồ thị con phải mất hàng tuần để được lập chỉ mục. Tôi không nghĩ GIP hiện không đưa ra bất kỳ điều khoản đặc biệt nào cho những trường hợp này, cổng cần phải xử lý chúng.

Pierre |Chain-Insights.eth: Vậy chúng ta có phải thực hiện các giao thức cho mọi cổng trong mọi sơ đồ con không? Điều này không có ý nghĩa với tôi. Chúng ta có bao nhiêu ô phụ 10.400???

Chúng ta nên tính toán CU (Đơn vị máy tính) trong thỏa thuận và điều chỉnh theo thị trường (cầu so với nhà cung cấp (cung)).

Matias: Chúng ta có nhất thiết phải có thỏa thuận cho từng cổng cho mỗi sơ đồ con không? Vâng, hy vọng điều này được tự động hóa. Người lập chỉ mục đặt số GRT tối thiểu họ cần trả cho mỗi chỉ mục chặn trên mỗi thực thể lưu trữ và trên mỗi chuỗi, do đó, khi một cổng cung cấp giao thức lập chỉ mục, giao thức đó sẽ tự động được chấp nhận hoặc bị từ chối. Hy vọng những thỏa thuận này sẽ mang lại lợi nhuận tổng thể. Chúng tôi biết rằng trong tập hợp con các giao thức được cung cấp cho bạn, một số có thể mất tiền và một số có thể kiếm được nhiều tiền hơn và ý tưởng là, về tổng thể, các giao thức này là kinh tế. Thuật toán lựa chọn bộ chỉ mục ưu tiên những người lập chỉ mục đã chọn nhiều tập bản đồ phụ khác nhau, bởi vì nếu chúng tôi không có các đơn vị tính toán, như bạn đã đề cập, thì bất kỳ proxy nào chúng tôi đưa ra sẽ không đủ chính xác để giúp mọi giao thức đều có lợi nhuận. Chúng tôi hy vọng rằng nếu mỗi người lập chỉ mục cung cấp đủ các giao thức lập chỉ mục thì đây sẽ trở thành một sự tổng hợp kinh tế.

Nói tóm lại, việc chấp nhận thỏa thuận phải được tự động hóa theo các tham số do người lập chỉ mục đặt ra, và sau đó, về tổng thể, túi thỏa thuận được cung cấp cho người lập chỉ mục phải đủ sinh lời.

Pierre |Chain-Insights.eth: Mô hình chi phí đã được thử trước đây, tôi không nghĩ có ai đã sử dụng vì giao thức đang điều chỉnh giá một cách linh hoạt.

Matias: Những gì tôi vừa mô tả là đại diện cho "công việc đã hoàn thành" và bạn có thể coi nó như một mô hình chi phí. Thị trường chắc chắn tốt hơn và chúng tôi đang nỗ lực hướng tới điều đó nhưng chúng tôi chưa đạt đến mức đó nên ý tưởng là đây là bước đệm cho thị trường vì như bạn đã đề cập nếu chúng tôi tập trung thiết lập các đại lý ở rìa và các nút Trong cổng và proxy không siêu chính xác, thì rõ ràng việc phát hiện giá, một chức năng của nó, sẽ không tối ưu. Vì vậy, chúng tôi muốn thoát khỏi tình trạng này càng nhanh càng tốt, nhưng hiện tại, đó là điều tốt nhất chúng tôi có thể làm cho MVP. Có một quy trình công việc khác đòi hỏi phải thực hiện một thử nghiệm khí biểu đồ con để xem liệu chúng ta có thể hiểu một cách chắc chắn rằng cần bao nhiêu công sức để lập chỉ mục các biểu đồ con và sau đó, quan trọng nhất là xây dựng thị trường. Nhưng đây là điều cuối cùng và không phải là một phần của GIP này.

Vince | Nodeify: Chúng ta có tính trung bình các chi phí lập chỉ mục này không? Đường cong trần và chuông sẽ cực kỳ cao, tức là Hetzner so với AWS hoặc Google Cloud, mà không đưa kim loại trần tự lưu trữ vào phương trình. Có chi phí đồng bộ hóa/lập chỉ mục, nhưng cũng có chi phí yêu cầu cho mỗi mạng. (Ethereum 4 TB, Arbitrum One, 20+ TB)

Matias: Bây giờ chúng ta bước vào cơ thể vật chất. Điều này rất thú vị. Chúng tôi rất vui được trò chuyện với bạn hoặc bất kỳ ai có mối quan ngại này. Chúng tôi sẵn lòng đưa ra quyết định sơ bộ về giá dựa trên nhiều dữ liệu nhất có thể. Chúng tôi biết rằng một số bộ chỉ mục lớn có cấu trúc rất khác so với các bộ chỉ mục nhỏ và chúng tôi muốn đảm bảo rằng giao thức lập chỉ mục có thể hỗ trợ nhiều bộ chỉ mục khác nhau. Điều này có thể có nghĩa là các thỏa thuận lập chỉ mục sẽ mang lại nhiều lợi nhuận hơn cho những người lập chỉ mục có quy mô kinh tế, nhưng điều này không loại trừ những người lập chỉ mục nhỏ hơn. Phần lớn là về việc bao gồm chúng. Vì vậy, càng có nhiều dữ liệu, chúng ta càng có thể đưa ra quyết định tốt hơn. Đó là một hành động cân bằng nhưng chúng tôi chắc chắn muốn đảm bảo rằng những người lập chỉ mục nhỏ hơn và những người lập chỉ mục mới nổi có thể tham gia vào hệ thống.

Matthew Darwin |Pinax: Tôi nghĩ người lập chỉ mục nên chia sẻ (ngoài chuỗi) "lượng không gian" mà mỗi mạng chiếm và sau đó cổng có thể sử dụng thông tin đó để định giá khác nhau cho mỗi chuỗi?

Matias: Có chi phí RPC và tỷ lệ số lượng thực thể lưu trữ trên GB trên mỗi sơ đồ con cũng rất khác nhau. Có rất nhiều bộ phận chuyển động. Tất nhiên, sẽ thật tuyệt nếu có dữ liệu này. Thật tuyệt vời khi biết được ngoài dung lượng trên mỗi mạng, chẳng hạn như số tiền bạn trả cho dung lượng đó, vì chạy trên kim loại trần khác với Google Cloud hoặc bất kỳ thứ gì khác. Chúng tôi rất vui khi tính đến tất cả những điều này.

Matthew Darwin |Pinax: Nhưng "chỉ số khối" cũng có thể bao gồm kích thước... Cổng biết StartBlock so với CurrentBlock, vì vậy nó có thể được bao gồm trong giá.

Matias: Tôi không chắc ý bạn là cỡ nào...chính xác là cỡ nào?

Matthew Darwin |Pinax: Nhưng "chỉ số khối" cũng có thể bao gồm kích thước... Cổng biết StartBlock so với CurrentBlock, vì vậy nó có thể được bao gồm trong giá.

Matias: Tôi không chắc ý bạn là cỡ nào...chính xác là cỡ nào?

Matthew: Điều tôi muốn nói là, từ nhận xét trước đây của tôi về kích thước hoặc lượng không gian được chiếm bởi mạng chia sẻ bộ chỉ mục, thực sự nếu một sơ đồ con có khối bắt đầu và khối hiện tại, khi cổng gửi giá, nó cần số lượng khối được lập chỉ mục là một chỉ báo cho biết bộ chỉ mục cần bao nhiêu dung lượng để chạy nút RPC. Bởi vì bạn biết đấy, nếu bạn yêu cầu lập chỉ mục 300 triệu khối trong Arbitrum, thì đó là một con số rất khác so với 18 triệu khối trong Ethereum. Tôi hy vọng các cổng sẽ trả nhiều tiền hơn cho các ví dụ Ethereum.

Matias: Để đáp ứng điều này, mỗi khối trên mỗi chuỗi có một mức giá khác nhau. Các đại lý đã xem xét điều này. Một lần nữa, nó sẽ không hoàn hảo, nhưng chúng tôi hy vọng nó hoạt động.

Vince | Nodeify: Tôi hy vọng một ngày nào đó chúng tôi có thể cung cấp các kho lưu trữ thay vì các nút đầy đủ. Số lượng người lập chỉ mục sẵn có sẽ tăng lên đáng kể và khi đó chúng tôi có thể tính phí đầy đủ thay vì tính phí theo yêu cầu lưu trữ, điều này cũng sẽ giảm giá cho khách hàng vì nhiều khách hàng sẽ không cần hỗ trợ lưu trữ.

Matias: Tôi cho rằng bạn đang đề cập đến các tình tiết phụ yêu cầu du hành thời gian. Tôi không có bình luận nào về đề xuất này, nhưng tôi nghĩ vẫn còn chỗ để cải thiện ở đó vì thực sự không có cách nào để biết liệu người tiêu dùng có sử dụng nó hay không hoặc có bao nhiêu người tiêu dùng thực sự đang sử dụng tính năng du hành thời gian.

Bình luận trò chuyện:

Matthew Darwin |Pinax: Tôi nghĩ thế là đủ rồi. Vince | Nodeify, hỗ trợ theo dõi và không theo dõi.

Slimchance: Các nút lưu trữ không được sử dụng để du hành thời gian mà dành cho các cuộc gọi Ethereum. Cần có nút lưu trữ để thực thi sơ đồ con của eth_calls, ngay cả khi không có truy vấn du hành thời gian.

Vince | Nodeify: Đây là con số rất nhỏ, chủ yếu sử dụng dữ liệu mới nhất.

Cơ hội mong manh: Du hành thời gian có liên quan đến việc cắt tỉa - những câu hỏi tương tự có thể được hỏi về vấn đề này.

Matthew Darwin |Pinax: Siêu dữ liệu của sơ đồ con sẽ cho bạn biết trước liệu bạn cần nút lưu trữ hay nút đầy đủ.

Pierre |Chain-Insights.eth: Xin lỗi, hiện tại tôi phản đối đề xuất này. Việc lập chỉ mục các đồ thị con không có lợi và làm tăng thời gian cũng như nguồn lực của người lập chỉ mục trong việc quản lý các giao thức này. Nó nên được tự động hóa. Đối với một dự án tiền điện tử trị giá 2 tỷ USD, điều này vô nghĩa và không phù hợp với đề xuất Sơ đồ tri thức.

Matias: Hoan nghênh phản hồi. Tôi không chắc có vấn đề gì mà tôi có thể giải quyết cụ thể hay không nhưng tôi rất vui được trò chuyện.

Abel | GraphOps: Pierre, bạn có muốn thêm một số ngữ cảnh bổ sung vào trò chuyện hoặc giọng nói không?

Pierre giải thích: Tôi biết bạn đã cố gắng hết sức để đưa ra đề xuất, nhưng tôi thấy có nhiều thay đổi với các bản cập nhật phần mềm và chúng tôi thậm chí còn chưa gỡ lỗi các phiên bản mới của Graph Node. Bây giờ, có một đề xuất cho Sơ đồ tri thức, không chỉ là Arbitrum hay Ethereum; nó sẽ là Sơ đồ tri thức. Có rất nhiều đề xuất, nhưng tôi có cảm giác rằng không ai nói chuyện với nhau để đưa ra những đề xuất nhất quán với nhau. Với tư cách là người lập chỉ mục, tôi là người lập chỉ mục mới chứ không phải là người có kinh nghiệm, nhưng tôi thấy rằng chúng tôi đã phải làm việc trên [đồ thị con] mà chúng tôi muốn lập chỉ mục và việc này không mất hàng tuần - Tôi có một số ô phụ, tôi muốn để lập chỉ mục trong ba tháng. Phải mất một thời gian dài và rất nhiều nguồn lực, và lợi nhuận thu được bây giờ không bền vững. Tất nhiên, nếu tôi có một số hiệu trưởng sẵn sàng đầu tư nhiều tiền, nó có thể mang lại lợi nhuận theo cách nào đó. Ngay cả Yaniv cũng nói rằng thiết kế của giao thức The Graph có một số thiếu sót, nhưng chúng tôi đang nỗ lực để giải quyết những thứ còn tồn tại một số thiếu sót. Hãy khắc phục những thiếu sót và sau đó bạn có thể chế tạo. […] Tôi không nghĩ sự liên kết đó là điều tôi mong đợi.

Tôi thấy bạn muốn giải quyết một số vấn đề và có nhiều cánh cổng, nhưng sau đó nó lại trở thành một công việc toàn thời gian. Liệu nó có quay trở lại đủ để bền vững không? Tôi không thể biết chúng tôi sẽ nhận được bao nhiêu GRT khi thực hiện thủ công tất cả giao thức và quản lý này? Giai đoạn đầu tiên của đề xuất sẽ đưa nhiều công việc hơn vào tự động hóa. […]

Matias: Bây giờ tôi đã hiểu mối quan tâm của bạn là tự động hóa. Kỳ vọng ở đây là việc xuất bản và thu thập giao thức được tự động hóa, do đó, người lập chỉ mục chỉ cần hiểu và đặt giá cho số tiền thưởng mà họ sẵn sàng nhận cho mỗi thực thể được lưu trữ trong mỗi chuỗi và cho mỗi chỉ mục bị chặn. Sau đó, ngăn xếp chỉ mục sẽ tự động chấp nhận mọi giao thức phù hợp với các tham số này. Vì vậy, nếu chúng tôi làm đúng, nếu proxy đủ tốt thì điều này sẽ được chọn tham gia và tự động theo quan điểm của người lập chỉ mục. Hy vọng rằng nếu chúng tôi làm sai một chút thì nhìn chung nó sẽ mang lại lợi nhuận cho người lập chỉ mục. Điều này có nghĩa là bằng cách tự động hóa mọi thứ từ đầu, chúng tôi có thể nỗ lực làm cho mọi việc trở nên chính xác và công bằng hơn về mặt lợi nhuận cho tất cả những người tham gia.

Pierre: Được rồi, cảm ơn bạn. Điều duy nhất tôi muốn bạn biết là nếu bạn đặt mức tối thiểu, sẽ luôn có một công ty chỉ số tính phí ít hơn và sẽ thắng nhiều hơn vì một số lý do, vì vậy nó sẽ là mức tối thiểu và thấp. cuối cùng, các công ty chỉ số lớn sẽ nói rằng tôi đã xong việc này, tôi sẽ đi nơi khác. […]

Matias: Điều tôi đang mô tả như một phần của MVP, có lẽ là lần lặp đầu tiên của các lần lặp trên chuỗi, là giá do cổng đặt ra và có giá cho mỗi người lập chỉ mục. Vì vậy, việc chấp nhận hay từ chối thực sự là tùy thuộc vào người lập chỉ mục, nhưng họ không thể hạ giá. Cách cổng đặt giá hoặc mức giá mà cổng có thể đặt là điều chúng tôi đang nghiên cứu và đó là lý do tại sao tôi yêu cầu dữ liệu và cuộc trò chuyện. Ý tưởng là cổng đặt giá ở mức giúp ngay cả những người mới và những người lập chỉ mục nhỏ cũng có thể sinh lời, để chúng tôi có thể khuyến khích sự tham gia rộng rãi vào phần này của giao thức và đảm bảo rằng phần này có thể được phân cấp nhất có thể.

Rem | Edge & Node: Chúng tôi sẽ làm việc về tự động hóa và có thể không phải tất cả những người lập chỉ mục đều tham gia vào bản phát hành MVP đầu tiên. Về lâu dài, kế hoạch của chúng tôi là giảm bớt khối lượng công việc mà người lập chỉ mục yêu cầu để chọn các đồ thị con liên quan đến những gì chúng tôi có hiện tại.

Vince | Nodeify nói: Nếu có thì đó sẽ là các công ty lớn sử dụng giá cắt cổ để loại các công ty nhỏ ra khỏi hoạt động kinh doanh vì họ có đủ khả năng để làm như vậy cho đến khi họ biến mất.

MoonBoi: 📢 —người lập chỉ mục-thông báo

Nếu bất kỳ người lập chỉ mục nào muốn liên hệ với chúng tôi để chúng tôi có thể hiểu sâu hơn về chi phí điều hành doanh nghiệp của họ thì chúng tôi rất mong nhận được phản hồi từ bạn. Chúng tôi đang nỗ lực để đảm bảo đề xuất này bền vững và một trong những nỗ lực của chúng tôi là đảm bảo rằng các cơ quan lập chỉ mục thanh toán có thể nhận được phản ánh chi phí công việc mà họ cung cấp.

Liên kết ở trên là thông báo Discord của chúng tôi từ tuần trước.

Matias: Nếu bạn có bất kỳ mối quan tâm nào khác, bạn luôn có thể liên hệ với tôi sau hoặc để lại nhận xét trên diễn đàn để mọi người đều có thể hưởng lợi. Tôi sẽ rất biết ơn nếu những người lập chỉ mục liên hệ trực tiếp với chúng tôi ([email protected]) để giúp chúng tôi nghiên cứu về giá, điều này rất quan trọng để đảm bảo sự tham gia rộng rãi.

(Vui lòng theo dõi blog để biết các thuật ngữ chuyên môn liên quan, nhận xét, thư viện mã, siêu liên kết, v.v.)

#BlockchainDataIndex #ThegGraph #web3data