Autor: Piotr Nowicki

W materiałach dotyczących Cyberspace CRATOS bywa przedstawiany zarówno jako jeden z tokenów platformy, jak i mechanizm związany z delegowaniem głosu oraz budowaniem siły liderów. Może to prowadzić do wrażenia, że użytkownik, udzielając komuś delegacji, przekazuje mu swoje tokeny podobnie jak kryptowalutę.

Docelowo CRATOS powinien działać inaczej.

Nie powinien być walutą, nagrodą za aktywność ani cyfrowym aktywem, którym można handlować. CRATOS ma reprezentować coś znacznie ważniejszego: osobiste prawo człowieka do współdecydowania.

Najprościej można to ująć w jednym zdaniu:

CRATOS określa, czyj głos istnieje, natomiast delegacja wskazuje, kto może ten głos wykonać.

CRATOS nie jest kryptowalutą

Samo użycie słowa „token” może sugerować, że CRATOS będzie działał podobnie jak Bitcoin, Ethereum albo tokeny użytkowe znane z projektów Web3. Takie rozumienie byłoby jednak sprzeczne z demokratycznym przeznaczeniem systemu.

CRATOS nie powinien być:

• kupowany za pieniądze;
• sprzedawany innym użytkownikom;
• zdobywany za publikowanie treści;
• przekazywany jako darowizna;
• przedmiotem spekulacji;
• gromadzony przez najbogatszych uczestników platformy.

Gdyby można było kupować CRATOS, w praktyce oznaczałoby to możliwość kupowania wpływu politycznego lub społecznego. Dlatego fundamentem systemu powinna pozostać zasada:

Jeden zweryfikowany człowiek posiada jeden podstawowy mandat w danym procesie demokratycznym.

CRATOS powinien być więc niezbywalnym cyfrowym mandatem związanym z tożsamością użytkownika. Można porównać go do cyfrowego prawa wyborczego, które może być wykonywane osobiście albo przez wybranego pełnomocnika.

Jeden człowiek, ale wiele kontekstów

Prawo głosu nie zawsze działa w jednym, globalnym obszarze. Ta sama osoba może być jednocześnie:

• mieszkańcem gminy;
• członkiem stowarzyszenia;
• pracownikiem organizacji;
• uczestnikiem grupy tematycznej;
• członkiem rady lub zarządu;
• wyborcą w konkretnych prawyborach.

Dlatego CRATOS powinien działać kontekstowo. Użytkownik może posiadać mandat w określonej społeczności, organizacji, grupie, kategorii tematycznej albo konkretnym głosowaniu.

Członkostwo w jednej grupie nie może automatycznie dawać prawa głosu w innej. Podobnie delegacja udzielona w sprawach lokalnych nie powinna obejmować głosowań finansowych, organizacyjnych czy personalnych, jeżeli użytkownik wyraźnie tego nie postanowił.

CRATOS a delegacja głosu

Najważniejsze jest rozdzielenie dwóch elementów systemu.

CRATOS jest źródłowym prawem głosu przypisanym do konkretnej osoby. Delegacja jest cyfrowym pełnomocnictwem określającym, kto może czasowo wykonywać to prawo.

Wyobraźmy sobie, że Anna posiada jeden CRATOS w społeczności swojej gminy. Interesuje się edukacją, ale nie ma czasu śledzić wszystkich spraw dotyczących transportu publicznego. Ufa natomiast Piotrowi, który zajmuje się komunikacją miejską i zna lokalne problemy.

Anna może udzielić Piotrowi delegacji ograniczonej wyłącznie do kategorii „Transport”.

W wyniku tej operacji CRATOS Anny nie opuszcza jej konta i nie staje się własnością Piotra. System zapisuje natomiast cyfrowe pełnomocnictwo zawierające między innymi:

• tożsamość osoby udzielającej delegacji;
• tożsamość delegata;
• społeczność lub organizację, której dotyczy delegacja;
• zakres tematyczny;
• datę rozpoczęcia i ewentualnego zakończenia;
• zgodę albo zakaz dalszego przekazywania mandatu;
• aktualny status pełnomocnictwa.

Piotr otrzymuje możliwość wykonywania głosu Anny wyłącznie w ustalonym zakresie. W sprawach edukacji, zdrowia lub finansów Anna nadal głosuje samodzielnie.

Czy CRATOS trafia na konto delegata?

Nie. To jeden z najważniejszych warunków bezpieczeństwa całego systemu.

Delegacja nie powinna powodować transferu własności tokena. Piotr nie może sprzedać CRATOS należącego do Anny, zatrzymać go po wygaśnięciu pełnomocnictwa ani wykorzystać poza zakresem delegacji.

System może pokazywać, że Piotr dysponuje określoną siłą głosu, ale powinna być ona obliczana dynamicznie:

Siła głosu delegata = jego własny mandat + wszystkie aktywne delegacje obowiązujące w danym kontekście.

Jeżeli Piotr posiada własny CRATOS i otrzymał 99 aktywnych delegacji, jego aktualna siła głosu wynosi 100. Nie oznacza to jednak, że jest właścicielem 100 tokenów. Właścicielami mandatów pozostaje 100 różnych osób.

To rozróżnienie ma fundamentalne znaczenie. Lider otrzymuje możliwość reprezentowania innych ludzi, ale nigdy nie przejmuje ich prawa do głosu.

Czasowe wstrzymanie delegacji

Użytkownik powinien mieć możliwość czasowego wyłączenia pełnomocnictwa bez konieczności całkowitego usuwania relacji z delegatem.

Jeżeli Anna czasowo wstrzyma delegację udzieloną Piotrowi, system zmieni jej status z aktywnego na zawieszony.

Technicznie oznacza to, że:

• CRATOS nadal pozostaje przypisany do Anny;
• Piotr przestaje wykonywać jej głos;
• siła głosu Piotra zmniejsza się o jeden;
• Anna odzyskuje możliwość osobistego głosowania;
• pełnomocnictwo pozostaje w historii systemu;
• delegacja może zostać wznowiona ręcznie albo automatycznie w określonym terminie.

Nie dochodzi do spalania tokena, jego ponownej emisji ani przesyłania pomiędzy portfelami. Zmienia się wyłącznie status upoważnienia do wykonywania mandatu.

Taki mechanizm może działać podobnie do czasowego zastrzeżenia dokumentu. Użytkownik zachowuje pełną kontrolę i jednym działaniem może zablokować korzystanie ze swojego głosu przez pełnomocnika.

Definitywne odwołanie delegacji

Drugą możliwością powinno być definitywne odwołanie konkretnego pełnomocnictwa.

Wówczas delegacja otrzymuje status odwołanej i nie może zostać ponownie aktywowana. Delegat natychmiast traci wynikające z niej uprawnienie, a użytkownik wraca do samodzielnego wykonywania mandatu albo może udzielić nowej delegacji innej osobie.

Historia pełnomocnictwa nie powinna być usuwana. Musi pozostać w bezpiecznym rejestrze audytowym jako dowód:

• kiedy delegacja została udzielona;
• czego dotyczyła;
• przez jaki czas obowiązywała;
• kiedy została zawieszona lub odwołana;
• kto zatwierdził poszczególne operacje.

„Odwołanie na stałe” powinno oznaczać definitywne zamknięcie konkretnego pełnomocnictwa. Nie może natomiast pozbawiać właściciela mandatu prawa do podjęcia nowej decyzji w przyszłości. Jeżeli Anna po roku ponownie zechce zaufać Piotrowi, powinna utworzyć nowe pełnomocnictwo i ponownie je zatwierdzić.

Co z głosem już oddanym przez delegata?

To jedno z najważniejszych zagadnień technicznych w całym systemie płynnej demokracji.

Załóżmy, że Piotr dysponuje 100 mandatami i oddaje głos w trwającym głosowaniu. Następnie Anna odwołuje swoją delegację.

System nie może przechowywać decyzji Piotra jako jednej nierozdzielnej paczki „100 głosów”. Musi potrafić ustalić, z jakich mandatów wynikała jego siła. Dzięki temu może wyłączyć wyłącznie udział należący do Anny, bez wpływania na pozostałych 99 uczestników.

Rekomendowana zasada jest następująca:

• do momentu zamknięcia głosowania użytkownik może odzyskać swój mandat;
• odwołanie delegacji usuwa z decyzji delegata część pochodzącą od osoby odwołującej pełnomocnictwo;
• właściciel może następnie zagłosować osobiście;
• osobisty głos właściciela ma pierwszeństwo przed delegacją;
• po zamknięciu i zatwierdzeniu wyniku odwołanie nie zmienia zakończonego głosowania.

W szczególnie formalnych procesach można ustanowić wcześniej ogłoszony moment zamrożenia delegacji. Po jego przekroczeniu zmiany obowiązywałyby dopiero w kolejnych głosowaniach. Taka reguła musi być jednak jednoznacznie przedstawiona uczestnikom przed rozpoczęciem procesu.

CRATOS_PROXY jako licznik, a nie kolejny token

W dokumentacji Cyberspace pojawia się również pojęcie CRATOS_PROXY. Najlepszym rozwiązaniem byłoby traktowanie go nie jako osobnego tokena, lecz jako aktualnego wyniku obliczeń.

CRATOS_PROXY może pokazywać, jaką liczbę mandatów dana osoba reprezentuje obecnie w konkretnej społeczności, kategorii albo głosowaniu.

Jeżeli jedna z delegacji zostanie zawieszona, wynik natychmiast się zmniejsza. Jeżeli zostanie wznowiona, ponownie wzrasta. Jeżeli właściciel mandatu zagłosuje osobiście, jego głos zostaje odłączony od siły delegata w tym konkretnym procesie.

Dzięki temu nie tworzymy dodatkowych tokenów, których liczba mogłaby się rozjechać z rzeczywistą liczbą uprawnionych osób.

Delegacja jako cyfrowe pełnomocnictwo

Delegacja CRATOS powinna mieć charakter cyfrowego pełnomocnictwa. W zwykłych procesach społecznościowych może być zatwierdzana za pomocą uwierzytelnienia użytkownika. W procesach formalnych może wykorzystywać CyberID, podpis kwalifikowany albo inne mechanizmy silnego potwierdzenia tożsamości.

Nie oznacza to jednak, że dane osobowe i treść oddanych głosów powinny być publicznie zapisywane na blockchainie.

Bezpieczna architektura powinna przechowywać dane osobowe oraz szczegóły upoważnienia w systemie chronionym, natomiast w niezmiennym rejestrze umieszczać jedynie kryptograficzne potwierdzenia najważniejszych zdarzeń:

• utworzenia delegacji;
• zmiany jej zakresu;
• zawieszenia;
• wznowienia;
• odwołania;
• wygaśnięcia.

Pozwala to pogodzić audytowalność z ochroną prywatności i tajnością głosowania.

Ochrona przed podwójnym głosowaniem

System musi zagwarantować, że jeden mandat nie zostanie wykorzystany jednocześnie przez właściciela i delegata.

Jeżeli Anna odda głos osobiście, Piotr nie może już użyć jej mandatu w tym samym głosowaniu. Jeżeli wcześniej zagłosował w jej imieniu, osobista decyzja Anny — podjęta przed zamknięciem głosowania — powinna zastąpić udział wykonany przez delegata.

System powinien także:

• wykrywać pętle delegacji;
• uniemożliwiać kopiowanie mandatów;
• respektować zakres i termin pełnomocnictwa;
• kontrolować dopuszczalną głębokość dalszej delegacji;
• zachowywać pełną historię zmian;
• natychmiast przeliczać siłę delegatów;
• chronić tajność indywidualnych decyzji.

Domyślnie dalsze przekazywanie otrzymanego mandatu powinno być zabronione. Mogłoby zostać dopuszczone wyłącznie wtedy, gdy właściciel głosu wyraźnie się na to zgodzi.

Popularność to nie to samo co mandat

CRATOS pozwala odróżnić popularność od rzeczywistego zaufania społecznego.

Liczba obserwujących, polubień czy komentarzy pokazuje zasięg użytkownika, ale nie oznacza, że inni są gotowi powierzyć mu prawo reprezentowania ich w podejmowaniu decyzji.

Lider posiadający wiele aktywnych delegacji dysponuje realnym, ale jednocześnie odwoływalnym mandatem. Jego pozycja nie jest nadawana raz na kilka lat. Zależy od zaufania, które może się zwiększać, zmniejszać albo zostać wycofane.

To zasadnicza różnica pomiędzy klasycznym systemem przedstawicielskim a płynną demokracją. Lider nie otrzymuje głosów na własność. Może z nich korzystać tylko tak długo, jak długo ludzie chcą być przez niego reprezentowani.

Głos pozostaje własnością obywatela

CRATOS nie powinien być rozumiany jako token przekazywany od jednej osoby do drugiej. Jest cyfrowym mandatem zakotwiczonym w tożsamości człowieka.

Delegować można wykonywanie prawa głosu, ale nie jego własność.

Użytkownik może samodzielnie głosować, czasowo powierzyć mandat ekspertowi, ograniczyć pełnomocnictwo do wybranej kategorii, wstrzymać je, wznowić albo definitywnie odwołać. W każdym z tych przypadków źródłowy CRATOS pozostaje przy swoim właścicielu.

Na tym polega najważniejsza idea płynnej demokracji rozwijanej w Cyberspace:

Możesz powierzyć komuś swój głos, ale nigdy nie przestajesz być jego właścicielem.

CRATOS jest więc cyfrowym mandatem obywatela w ruchu — głosem, który może być wykonywany osobiście lub przez zaufanego pełnomocnika, lecz zawsze pozostaje pod ostateczną kontrolą człowieka, do którego należy.