January 14, 2022

Accounting for stake in threshold signature schemes

@bohgdanm

Rozliczanie udziałów w schematach podpisów progowych

Co to jest sygnatura progowa i jak jest wykorzystywana w Axelarze?

Schemat sygnatury progowej umożliwia zbiorowi stron podział tajnego klucza dla schematu sygnatury w taki sposób, że dowolny podzbiór t+1 lub więcej stron może współpracować w celu wygenerowania sygnatury, ale żaden podzbiór t lub mniej stron nie może wygenerować podpisu, a nawet dowiedzieć się jakichkolwiek informacji o tajnym kluczu.

Protokoły progowe istnieją dla najpowszechniej stosowanych obecnie schematów podpisów, w tym schematu ECDSA używanego w Bitcoin i Ethereum. Podpisy złożone przez protokół progowy są nie do odróżnienia od zwykłych (nieprogowych) podpisów ECDSA.

Walidatory Axelar wykorzystują schematy sygnatur progowych do wspólnego utrzymywania kont na różnych łańcuchach bloków, takich jak Bitcoin i Ethereum. Konta te umożliwiają walidatorom Axelar odblokowanie aktywów w łańcuchu A w celu przeniesienia tych aktywów do łańcucha B.

Potrzeba ważonych podpisów progowych

Sieć Axelar korzysta z konsensusu dowodu stawki; może istnieć nierówny podział udziałów między walidatorami Axelar. Warto pomyśleć o prostym przykładzie z trzema walidatorami Axelar: Alice, Bob i Claire, których stawki procentowe wynoszą 47%, 17% i 36%.

Podstawową zasadą jest to, że aktywa na rachunkach progowych mogą zostać przeniesione tylko wtedy, gdy wystarczająco wysoka część stawki Axelar wyrazi zgodę na ich przeniesienie. Kontynuując nasz przykład, załóżmy, że ułamek wynosi 40%, więc tylko te podzbiory Alicji, Boba i Claire, których łączny udział przekracza 40%, mogą przenosić aktywa. Tak więc Alice ma wystarczającą stawkę, aby sama przenosić aktywa, ale Bob musi współpracować z Claire, aby przenieść aktywa bez Alice.

Niestety, istniejące schematy podpisywania progów zakładają, że wszystkie strony w protokole mają równe uprawnienia do tworzenia podpisów. Naiwne użycie sygnatur progowych może przydzielić jeden udział tajnego klucza każdej z Alice, Boba i Claire. W tym przypadku nie ma wartości progowej t, która może osiągnąć strukturę dostępu, którą właśnie opisaliśmy:

  • Jeśli t>=1 to Alicja nie może sama złożyć podpisu, mimo że kontroluje >40% stawki Axelar.
  • Jeśli t<1, to albo Bob, albo Claire mogliby złożyć swój podpis samodzielnie, pomimo faktu, że żaden z nich nie kontroluje 40% udziałów Axelar.

Potrzebujemy sposobu na zreplikowanie naszej pożądanej struktury dostępu przy użyciu istniejących schematów sygnatur progowych.

Dodawanie wag do sygnatur progowych

Jedno rozwiązanie naszego problemu jest w zasadzie dość proste: przydziel każdemu walidatorowi wiele udziałów progowych proporcjonalnie do kwoty stawki kontrolowanej przez tego walidatora. Ale jest kilka nieznośnych skrajnych przypadków do rozwiązania.

Zacznijmy od nieco bardziej szczegółowego opisu rozwiązania, a następnie zobaczmy, jak radzi sobie z nieznośnymi skrajnymi przypadkami. Rozwiązanie przydziela cel n całkowitych udziałów progowych między walidatorami zgodnie z następującą metodą:

  1. Na początek każdy walidator otrzymuje 1 udział progowy za każdy ułamek stawki, który kontroluje 1/n, zaokrąglając w dół.
  2. Jeśli łączna liczba udziałów do tej pory jest mniejsza niż docelowa, przyznaj jeden dodatkowy udział na stronę w kolejności malejącej stawki, aż do osiągnięcia celu (należy również określić arbitralną zasadę łamania remisów).

Stosując tę ​​metodę do naszego przykładu, załóżmy, że celem jest n=100 wszystkich udziałów, a więc próg t=40. Następnie Alice dostaje 47 akcji, Bob 17, a Claire 36. Spokojnie!

Liczby w tym przykładzie dobrze się sprawdzają, ale co, jeśli liczby nie są aż tak ładne? Załóżmy zamiast tego, że stawki procentowe Alicji i Boba wynoszą 47,5% i 16,5%. Czy (Alice, Bob) powinny otrzymać (48, 16) czy (47,17) akcji? Zgodnie z powyższą procedurą, dodatkowa część przypada Alicji, a nie Bobowi.

Na pierwszy rzut oka wybór dodatkowego udziału Alicji w powyższym przykładzie może wydawać się arbitralny, więc zmotywujmy go innym przykładem. Załóżmy, że mamy 200 walidatorów z następującym rozkładem stawek:

  • 50 walidatorów ma 0,7% udziału
  • 50 walidatorów ma 0,6% udziałów
  • 50 walidatorów ma 0,4% udziału
  • 50 walidatorów ma 0,3% udziału

W tym przypadku jasne jest, że prawidłowy przydział 100 udziałów wygląda następująco:

  • 1 udział dla każdego walidatora z 0,6% lub 0,7% udziałem
  • 0 akcji dla każdego walidatora z 0,3% lub 0,4% udziałów

I taką właśnie alokację uzyskujemy z tego rozwiązania.

Rozważania wdrożeniowe

Przydzielenie wielu udziałów progowych na walidator jest koncepcyjnie proste, ale robienie tego w bibliotece oprogramowania zwiększa złożoność i księgowość na niskim poziomie w porównaniu z naiwną zasadą jeden udział na walidator.

Na przykład dodatkowe informacje o routingu muszą być dołączone do każdej wiadomości w protokole sygnatury progu. Nie wystarczy już zaimplementować „Alice wysyła wiadomość m do Boba”. Zamiast tego musimy zaimplementować „Alice #3 wysyła wiadomość m do Boba #7”. Oprogramowanie do podpisywania progów musi spakować i rozpakować dodatkowe metadane „#3”, „#7”.

Użytkownik biblioteki - walidator Axelar - nie powinien martwić się o routing. Zamiast tego walidator powinien wiedzieć tylko o tym, że „Alice wysyła wiadomość do Boba”. Rzeczywiście, jedyna różnica w stosunku do naiwnego typu „jeden udział na walidator” z punktu widzenia walidatora jest następująca: aby zainicjować protokół generowania klucza, walidator musi określić raz na początku protokołu, ile udziałów otrzyma każda ze stron. Biblioteka zajmuje się wszystkim innym. Po zainicjowaniu interfejs API biblioteki powinien być nie do odróżnienia od prostszego protokołu jeden udział na walidator.

Rozważ następujący schemat architektoniczny:

Walidator Axelar (Alice) ma przydzielone 3 udziały progowe. Otrzymuje skierowane do niej wiadomości z sieci Axelar. Router Alicji rozpakowuje każdą wiadomość na tyle, aby odkryć, który z jej udziałów (#1, #2, #3) jest ostatecznym miejscem docelowym wiadomości. Każdy udział jest administrowany przez oddzielną instancję protokołu progowego („instancja protokołu nr 1” itp. na diagramie). Każda instancja protokołu dodaje dane routingu do swoich wiadomości wychodzących i przesyła je bezpośrednio do sieci Axelar. Ostateczny wynik każdej instancji jest odpowiednio agregowany przez Alice zgodnie ze szczegółami podstawowego protokołu progowego, zanim pojedynczy, końcowy wynik zostanie przesłany do sieci Axelar.

Ten wynik końcowy może być również przechowywany w lokalnym magazynie danych Alicji do późniejszego wykorzystania. Na przykład, jeśli ostatecznym wynikiem jest progowy udział klucza tajnego, Alicja musi zapamiętać te tajne dane, aby w przyszłości uczestniczyć w podpisaniu wiadomości.