Question 1

Que sont Lava Network et LAVA ?

Accepted Answer

Lava Network est un réseau qui fournit des services d’API décentralisés pour l’accès aux données de blockchains. Les consommateurs achètent des abonnements afin d’obtenir des droits d’utilisation d’API, les fournisseurs exploitent des endpoints et fournissent les services, et LAVA est utilisé pour le staking, les incitations de service et la participation au réseau. Il ne remplace pas directement les blockchains auxquelles il donne accès : le rôle de Lava est d’organiser qui peut fournir des services de données, comment les consommateurs obtiennent ces services et comment les récompenses sont réglées sur la base d’une utilisation vérifiable.

Question 2

Quels sont les rôles de LAVA dans le réseau ?

Accepted Answer

LAVA sert à la fois à sécuriser le réseau et à coordonner les services de données. Les validateurs stakent des LAVA pour participer à la production de blocs et à la validation des transactions ; les fournisseurs stakent des LAVA, sélectionnent les spécifications d’API de leurs services et établissent des endpoints ; les délégateurs peuvent déléguer à des validateurs ou à des fournisseurs pour participer à la distribution des récompenses correspondantes. L’achat d’un abonnement par un consommateur ne signifie pas que tous les frais d’abonnement sont directement versés à un endpoint donné. L’abonnement définit d’abord les services disponibles et les conditions d’utilisation, puis le protocole distribue les parts correspondantes entre fournisseurs, validateurs, contributeurs et délégateurs selon les services valides et les règles de règlement.

Question 3

Qu’est-ce que le double staking de LAVA ?

Accepted Answer

Le double staking signifie que le staking ou la délégation d’un même montant de LAVA peut être associé simultanément aux rôles de validateur et de fournisseur. Les mêmes jetons sont donc exposés aux risques de la sécurité du consensus et de la fourniture de services, tout en pouvant participer aux récompenses des deux côtés. Son objectif est d’éviter un déséquilibre important entre les volumes stakés dans le pool des validateurs et celui des fournisseurs. Lorsqu’un staking est commencé du côté du fournisseur, un validateur doit être sélectionné simultanément ; lors d’une délégation du côté du validateur, aucun fournisseur ne doit être choisi immédiatement, et les jetons restent alors dans l’état « empty_provider », auquel une délégation à un fournisseur peut être ajoutée ultérieurement. Le staking effectif d’un fournisseur est également influencé par sa commission et son plafond de délégation ; le staking ne garantit donc pas le même rendement dans tous les cas.

Question 4

Comment les consommateurs obtiennent-ils des services d’API et comment les fournisseurs sont-ils sélectionnés ?

Accepted Answer

Les consommateurs achètent d’abord des plans d’abonnement définis par la gouvernance ; ces plans prévoient, sur une période donnée, des limites relatives au volume disponible, au nombre de fournisseurs, à la localisation géographique ou à des fonctions supplémentaires. Un abonnement peut créer des projets afin d’attribuer les droits d’utilisation aux développeurs ou aux applications. Au cours de chaque epoch, le protocole associe de manière pseudo-aléatoire les consommateurs et fournisseurs selon des facteurs tels que le staking des fournisseurs, la localisation géographique, les indicateurs de qualité de service, les extensions prises en charge et les paramètres des consommateurs. Seuls les fournisseurs appariés sont éligibles à demander des récompenses pour le service de ce consommateur ; l’appariement est mis à jour à chaque epoch afin de répartir le trafic et de réduire les risques de concentration ou de censure.

Question 5

Comment les récompenses de service des fournisseurs sont-elles prouvées et réglées ?

Accepted Answer

Après avoir traité des requêtes d’API hors chaîne, les fournisseurs conservent des enregistrements de relay signés avec des clés de consommateur, de développeur ou d’abonnement ; la signature constitue une preuve de la demande de service. Afin d’éviter de placer chaque requête on-chain, les unités de calcul (CU) des requêtes consécutives sont agrégées en sessions, et le fournisseur peut utiliser la dernière preuve agrégée d’une session pour effectuer une demande relay_payment. Les récompenses ne sont pas versées immédiatement à chaque appel d’API. La fenêtre de demande différée après la fin de l’epoch permet l’achèvement de l’agrégation de la session et permet aussi à la chaîne de vérifier l’appariement et d’empêcher les demandes multiples pour une même session. À la fin de l’abonnement ou lors du déclenchement mensuel, les CU cumulées servent à répartir le coût de l’abonnement selon l’utilisation du service ; après déduction des parts des validateurs et contributeurs, les fournisseurs distribuent le reste à leurs délégateurs conformément aux règles de commission.

Question 6

Comment fonctionnent l’offre de LAVA et le financement des incitations ?

Accepted Answer

La fonction de mint de Lava est désactivée ; le protocole ne crée donc pas de nouveaux LAVA par émission continue. Les premières incitations à la production de blocs et aux fournisseurs peuvent provenir de récompenses Bootstrap préalablement verrouillées dans un pool de récompenses et progressivement libérées selon les règles. Cela doit être distingué d’une « offre en circulation inchangée » : la libération du pool de récompenses modifie le parcours des jetons du pool vers les participants, mais ne constitue pas un nouveau mint ; les récompenses non réclamées et les jetons confisqués en raison de fraude réduisent l’offre. Les récompenses des fournisseurs sont aussi directement liées aux abonnements achetés par les consommateurs, et la gouvernance peut ajuster les prix des plans d’abonnement selon l’offre et la demande de jetons.

Question 7

Comment Lava relie-t-il la qualité de service aux incitations des fournisseurs ?

Accepted Answer

La qualité du service peut affecter la capacité d’un fournisseur à conserver ses récompenses et à obtenir de futurs appariements. Les consommateurs soumettent des rapports de qualité de service au cours d’une session, et les fournisseurs doivent joindre ces rapports lorsqu’ils réclament des récompenses ; l’absence de rapport peut entraîner la perte de la récompense, et des notes plus faibles peuvent aussi réduire les CU cumulées selon une ampleur définie par la gouvernance. Si un fournisseur refuse continuellement les connexions ou renvoie des erreurs répétées, les consommateurs peuvent signaler son état hors ligne au moyen de transactions de demande provenant d’autres fournisseurs. Au début de chaque epoch, le protocole évalue les rapports concernés ; lorsque l’écart entre l’utilisation rapportée et l’utilisation réclamée par ce fournisseur atteint le seuil défini par les règles, le fournisseur peut être jailed, temporairement incapable d’obtenir de nouveaux appariements jusqu’à la levée de cet état.

Prix de Lava Network (LAVA)