Initialement publié en anglais par StarkWare le 3 jun, 2020

La série sur Self-Custody, partie II

StarkEx est un moteur de scalabilité self-custodial. Nous avons décrit les différentes facettes d’un système self-custody, dont la scalabilité. Cet article décrit le mécanisme de mise à niveau que nous avons conçu pour garantir que StarkEx reste un système self-custody entièrement.

Il y a deux raisons pour mettre à jour le code d’un smart contract : de nouvelles fonctionnalités, ou la sécurité (bugs). La difficulté consiste à procéder à ces mises à niveau sans compromettre le caractère self-custody du système. Un remplacement « naïf » (en fait : malveillant) de la logique StarkEx permettrait à l’opérateur d’application de s’emparer de tous les actifs de l’utilisateur. StarkEx comprend un nouveau mécanisme de mise à niveau pour protéger les actifs des utilisateurs. Dans les grandes lignes, ce mécanisme utilise des minuteries et différentes sortes de cascades temporelles des smart contracts (plus de détails ci-dessous).

Le StarkEx Application Smart Contract (ASC) utilise le Proxy Pattern (suggéré par openZepplin), et en tant que tel a plusieurs sous-composants. Un contrat Proxy contient tout le stockage des fonds, à l’adresse (càd. un pointeur vers) d’un Logic Contract, qui définit la fonctionnalité. À partir du Contrat Proxy, nous appelons le Logic Contract en appelant les délégués (qui s’exécute dans le cadre du Contrat Proxy). La logique ASC StarkEx est donc définie par le logic contract. La logique ASC StarkEx est donc mise à jour en déployant un nouveau contrat et en mettant à jour le pointeur du Contrat Proxy. Les adresses du contrat du vérifieur et du contrat du Data Availability Committee (DAC) sont référencées dans le Contrat Logique, et non dans le Contrat Proxy (si vous souhaitez une mise à jour sur les différentes composantes de StarkEx, voici un aperçu).

Dans la phase I, nous avons un mécanisme de mise à niveau distinct pour chacun de ces trois contrats : Logic, Verifieur et DAC Toutes les opérations de mise à niveau ne peuvent être effectuées que par des adresses autorisées.

1. Logic Contract Upgrade :

• Mise à niveau : Le Contrat Proxy conserve une liste des adresses de version de Logic Contract. Une nouvelle version est verrouillée dans le temps pendant une période que nous désignons comme upgrade_activation_delay (définie à 28 jours) avant qu’elle ne devienne active. upgrade_activation_delay est défini de manière significative au-delà de la période de grâce de StarkEx Escape Hatch. Une seule de ces versions est active à un moment donné, mais l’administrateur autorisé peut immédiatement basculer entre les versions déverrouillées.

• Self Custody : La période de temps précédant le déverrouillage d’une nouvelle version permet aux utilisateurs d’examiner la nouvelle version. Les utilisateurs peuvent se désinscrire de StarkEx s’ils trouvent la nouvelle version inacceptable, et alerter les autres utilisateurs ainsi. Comme upgrade_activation_delay est nettement plus long que la période de grâce, les utilisateurs sont assurés de pouvoir retirer leurs fonds en temps voulu.

Examinons les autres contrats, qui fournissent tous deux un service de vérification : l’un est la vérification des épreuves STARK (le contrat vérifieur) et l’autre est la vérification de la data avability (le contrat DAC). Ils sont de nature similaire et sont donc utilisés par le logic contract, et mis à niveau, de la même façon.

1. Mise à jour du contrat du vérifieur :

• Mécanisme : Le logic contrat tient une liste des contrats vérifieur. Une preuve n’est considérée comme valable que si elle est acceptée par tous les vérifieurs. L’ajout d’un nouveau vérifieur au contrat est immédiat. La suppression d’un vérifieur est verrouillée dans le temps pour la durée de upgrade_activation_delay.

• Self-custody : L’objectif du vérifieur est d’accepter les preuves valides et de rejeter les preuves invalides. Pour des raisons de sécurité, nous autorisons l’ajout immédiat (sans délai) d’un nouveau vérifieur – notez qu’il s’agit d’un ajout immédiat et non d’un remplacement. Étant donné qu’une preuve doit être acceptée par tous les vérifieurs, les preuves non valables ne peuvent toujours pas être acceptées. Ce délai garantit que les vérifieurs déjà déployés ne peuvent pas être retirés immédiatement, ce qui permet à la communauté d’examiner un nouveau contrat ajouté.

1. DAC Contract Upgrade : modèle et raisonnement identiques aux Vérifier Contracts.

Pour mieux comprendre le caractère cumulatif de ces contrats de vérification, considérons la métaphore du tamis : un vérifieur est comme un « tamis » très fin qui ne laisse passer que des déclarations valides. Dans StarkEx, nous ne remplaçons pas simplement un « tamis » par un autre, mais exigeons plutôt qu’une instruction passe à travers les « tamis » préexistants et le nouveau « tamis » déployé. Le nouveau «tamis» ne peut pas valider une instruction invalide; il ne peut que restreindre davantage l’ensemble des instructions jugées valides. C’est exactement ce qui s’est passé avec la plupart des mises à jour du protocole de Bitcoin, qui étaient des soft fork : une fois qu’un soft fork est activée, les blocs précédemment invalides restent invalides et les blocs jusqu’alors valides peuvent désormais devenir invalides aussi.

Comme nous l’avons mentionné ci-dessus, la détection d’un risque de sécurité est l’une des principales motivations de la mise à niveau des smart contracts. Nous pouvons classer trois types de risques pour la sécurité :

1. Fonds bloqués :

• Risque : les fonds de l’utilisateur déposés sur un smart contract peuvent être bloqués en raison d’un bug (p.ex. le bug Parity).

• Atténuation : Ajout d’une nouvelle version de Logic Contract qui corrige le bug.

1. Fonds volés :

• Risque : Un bug dans le contrat peut permettre à des utilisateurs malveillants d’abuser de l’API et de voler des fonds du contrat. L’opérateur d’application StarkEx doit être en mesure de résoudre ce problème dès que possible, car le temps signifie littéralement de l’argent.

• Atténuation : La possibilité de passer immédiatement à une autre version du Logic Contrat (une fois la durée de verrouillage dépassée) atténue ce risque. Plus précisément, le système sera doté d’une version squelettique préchargée pour le retrait seulement. La version squelettique est un moyen efficace d’arrêter toutes les fonctionnalités du contrat, à l’exception des retraits de l’utilisateur.

1. Verifieur Soundness Bug : Ce type de bug, qui peut naturellement conduire à des fonds bloqués ou volés, mérite d’être discuté séparément, car StarkEx est un système basé sur zkp.

• Risque : Ce type de bug entraînerait l’acceptation par le Verifier Contract d’une transition d’état invalide. Cela pourrait altérer les soldes des utilisateurs et, en particulier, permettre le vol de fonds.

• Atténuation : Les Soundness bugs sont résolus par l’ajout immédiat d’un nouveau Verifier Contract (sans délai), puisque chaque transition d’état doit être acceptée par tous les vérifieurs déployés : le nouveau Verifier Contract, vraisemblablement déployé pour refuser cette transition invalide, suffira à le faire rejeter par le système.

Tom Brand, Lior Goldberg, Michael Riabzev

Traduction faite par @cleminso

Initialement publié en anglais par StarkWare le 3 jun, 2020

La série sur Self-Custody, partie II

StarkEx est un moteur de scalabilité self-custodial. Nous avons décrit les différentes facettes d’un système self-custody, dont la scalabilité. Cet article décrit le mécanisme de mise à niveau que nous avons conçu pour garantir que StarkEx reste un système self-custody entièrement.

Il y a deux raisons pour mettre à jour le code d’un smart contract : de nouvelles fonctionnalités, ou la sécurité (bugs). La difficulté consiste à procéder à ces mises à niveau sans compromettre le caractère self-custody du système. Un remplacement « naïf » (en fait : malveillant) de la logique StarkEx permettrait à l’opérateur d’application de s’emparer de tous les actifs de l’utilisateur. StarkEx comprend un nouveau mécanisme de mise à niveau pour protéger les actifs des utilisateurs. Dans les grandes lignes, ce mécanisme utilise des minuteries et différentes sortes de cascades temporelles des smart contracts (plus de détails ci-dessous).

Le StarkEx Application Smart Contract (ASC) utilise le Proxy Pattern (suggéré par openZepplin), et en tant que tel a plusieurs sous-composants. Un contrat Proxy contient tout le stockage des fonds, à l’adresse (càd. un pointeur vers) d’un Logic Contract, qui définit la fonctionnalité. À partir du Contrat Proxy, nous appelons le Logic Contract en appelant les délégués (qui s’exécute dans le cadre du Contrat Proxy). La logique ASC StarkEx est donc définie par le logic contract. La logique ASC StarkEx est donc mise à jour en déployant un nouveau contrat et en mettant à jour le pointeur du Contrat Proxy. Les adresses du contrat du vérifieur et du contrat du Data Availability Committee (DAC) sont référencées dans le Contrat Logique, et non dans le Contrat Proxy (si vous souhaitez une mise à jour sur les différentes composantes de StarkEx, voici un aperçu).

Dans la phase I, nous avons un mécanisme de mise à niveau distinct pour chacun de ces trois contrats : Logic, Verifieur et DAC Toutes les opérations de mise à niveau ne peuvent être effectuées que par des adresses autorisées.

1. Logic Contract Upgrade :

• Mise à niveau : Le Contrat Proxy conserve une liste des adresses de version de Logic Contract. Une nouvelle version est verrouillée dans le temps pendant une période que nous désignons comme upgrade_activation_delay (définie à 28 jours) avant qu’elle ne devienne active. upgrade_activation_delay est défini de manière significative au-delà de la période de grâce de StarkEx Escape Hatch. Une seule de ces versions est active à un moment donné, mais l’administrateur autorisé peut immédiatement basculer entre les versions déverrouillées.

• Self Custody : La période de temps précédant le déverrouillage d’une nouvelle version permet aux utilisateurs d’examiner la nouvelle version. Les utilisateurs peuvent se désinscrire de StarkEx s’ils trouvent la nouvelle version inacceptable, et alerter les autres utilisateurs ainsi. Comme upgrade_activation_delay est nettement plus long que la période de grâce, les utilisateurs sont assurés de pouvoir retirer leurs fonds en temps voulu.

Examinons les autres contrats, qui fournissent tous deux un service de vérification : l’un est la vérification des épreuves STARK (le contrat vérifieur) et l’autre est la vérification de la data avability (le contrat DAC). Ils sont de nature similaire et sont donc utilisés par le logic contract, et mis à niveau, de la même façon.

1. Mise à jour du contrat du vérifieur :

• Mécanisme : Le logic contrat tient une liste des contrats vérifieur. Une preuve n’est considérée comme valable que si elle est acceptée par tous les vérifieurs. L’ajout d’un nouveau vérifieur au contrat est immédiat. La suppression d’un vérifieur est verrouillée dans le temps pour la durée de upgrade_activation_delay.

• Self-custody : L’objectif du vérifieur est d’accepter les preuves valides et de rejeter les preuves invalides. Pour des raisons de sécurité, nous autorisons l’ajout immédiat (sans délai) d’un nouveau vérifieur – notez qu’il s’agit d’un ajout immédiat et non d’un remplacement. Étant donné qu’une preuve doit être acceptée par tous les vérifieurs, les preuves non valables ne peuvent toujours pas être acceptées. Ce délai garantit que les vérifieurs déjà déployés ne peuvent pas être retirés immédiatement, ce qui permet à la communauté d’examiner un nouveau contrat ajouté.

1. DAC Contract Upgrade : modèle et raisonnement identiques aux Vérifier Contracts.

Pour mieux comprendre le caractère cumulatif de ces contrats de vérification, considérons la métaphore du tamis : un vérifieur est comme un « tamis » très fin qui ne laisse passer que des déclarations valides. Dans StarkEx, nous ne remplaçons pas simplement un « tamis » par un autre, mais exigeons plutôt qu’une instruction passe à travers les « tamis » préexistants et le nouveau « tamis » déployé. Le nouveau «tamis» ne peut pas valider une instruction invalide; il ne peut que restreindre davantage l’ensemble des instructions jugées valides. C’est exactement ce qui s’est passé avec la plupart des mises à jour du protocole de Bitcoin, qui étaient des soft fork : une fois qu’un soft fork est activée, les blocs précédemment invalides restent invalides et les blocs jusqu’alors valides peuvent désormais devenir invalides aussi.

Comme nous l’avons mentionné ci-dessus, la détection d’un risque de sécurité est l’une des principales motivations de la mise à niveau des smart contracts. Nous pouvons classer trois types de risques pour la sécurité :

1. Fonds bloqués :

• Risque : les fonds de l’utilisateur déposés sur un smart contract peuvent être bloqués en raison d’un bug (p.ex. le bug Parity).

• Atténuation : Ajout d’une nouvelle version de Logic Contract qui corrige le bug.

1. Fonds volés :

• Risque : Un bug dans le contrat peut permettre à des utilisateurs malveillants d’abuser de l’API et de voler des fonds du contrat. L’opérateur d’application StarkEx doit être en mesure de résoudre ce problème dès que possible, car le temps signifie littéralement de l’argent.

• Atténuation : La possibilité de passer immédiatement à une autre version du Logic Contrat (une fois la durée de verrouillage dépassée) atténue ce risque. Plus précisément, le système sera doté d’une version squelettique préchargée pour le retrait seulement. La version squelettique est un moyen efficace d’arrêter toutes les fonctionnalités du contrat, à l’exception des retraits de l’utilisateur.

1. Verifieur Soundness Bug : Ce type de bug, qui peut naturellement conduire à des fonds bloqués ou volés, mérite d’être discuté séparément, car StarkEx est un système basé sur zkp.

• Risque : Ce type de bug entraînerait l’acceptation par le Verifier Contract d’une transition d’état invalide. Cela pourrait altérer les soldes des utilisateurs et, en particulier, permettre le vol de fonds.

• Atténuation : Les Soundness bugs sont résolus par l’ajout immédiat d’un nouveau Verifier Contract (sans délai), puisque chaque transition d’état doit être acceptée par tous les vérifieurs déployés : le nouveau Verifier Contract, vraisemblablement déployé pour refuser cette transition invalide, suffira à le faire rejeter par le système.

Tom Brand, Lior Goldberg, Michael Riabzev

Traduction faite par @cleminso