Smart Media Tokens Whitepaper [PL] cz. 5

Projektant SMT może chcieć wstępnie opublikować gwarancję, że ukryte wartości mieszczą się w określonym zakresie. Pola lower_bound i upper_bound zapewniają tę funkcję: ujawniona kwota, która nie znajduje się w podanym zakresie, jest traktowana tak samo, jak niezgodność hash.

Wszystkie ukryte pule finansowania mogą zostać ujawnione w dowolnym momencie. Dlatego też ICO z niewidocznym minimum lub limitem może zostać zaimplementowane poprzez proste dodanie operacji smt_cap_reveal_operation w tej samej transakcji co operacja smt_setup_operation. Interfejsy powinny zapewniać taką funkcjonalność.

Interfejs użytkownika powinien zapewniać, że kwoty jednorazowe podlegają zwrotowi. Powinien zmuszać użytkownika do ponownego wpisania kwoty i powtórzenia, jako potwierdzenia, że zostały wykonane kopie zapasowe.

Struktura danych strategii generowania SMT wygląda następująco:

struct smt_capped_generation_policy
{
smt_generation_unit pre_soft_cap_unit;
smt_generation_unit post_soft_cap_unit;
smt_cap_commitment min_steem_units_commitment;
smt_cap_commitment hard_cap_steem_units_commitment;
uint16_t soft_cap_percent = 0;
uint32_t min_unit_ratio = 0;
uint32_t max_unit_ratio = 0;
extensions_type extensions;
};

Uwaga: parametr max_token_units_generated nie pojawia się nigdzie w operacji. Powodem jest fakt, że jest to właściwie parametr pochodny: max_token_units_generated
= min_unit_ratio * hard_cap_steem_units.

Dodatkowo, smt_generation_policy definiowane jest jako static_variant, którego jedynym członkiem jest smt_capped_generation_policy:

typedef static_variant< smt_capped_generation_policy > smt_generation_policy;

Ten typedef pozwala potencjalnym przyszłym wersjom protokołów umożliwić dodatkową semantykę polityki generowania o różnych parametrach.

Przykład ICO

ALPHA chce sprzedać token tłumowi, aby zebrać fundusze tam, gdzie: 70% wpłaconego STEEM trafia na konto organizacji Alpha (@ alpha_org), 23% przekazanego STEEM trafia na konto założyciela A (@ founder_a), a 7% udziału STEEM trafia na konto założycielskie B (@ founder_b).

ALPHA definiuje jednostkę STEEM jako:

steem_unit = [["alpha_org", 70], ["founder_a", 23], ["founder_b", 7]]

Ta jednostka STEEM zawiera od 100 STEEM do 0,1 STEEM.

Za każdy 1 wniesiony STEEM, partner ALPHA otrzyma 5 tokenów ALPHA, a Konto Założyciela otrzyma 1 token ALPHA. Ten podział pięciu szóstych / jednej szóstej jest wyrażony jako:

token_unit = [["$from", 5], ["founder_c", 1]]

Współczynnik ten jest zdefiniowany w następującej strukturze danych:

struct smt_generation_unit
{
flat_map< account_name_type, uint16_t > steem_unit;
flat_map< account_name_type, uint16_t > token_unit;
};

Ta jednostka-token zawiera 6 ALPHA lub 0.0006 ALPHA (jeśli ALPHA ma 4 miejsca dziesiętne).

Następnie definiujemy stosunek jednostek jako relatywną szybkość, z jaką wysyłane są jednostki token_unit jako steem_unit. Aby dopasować specyfikację 6 ALPHA na 1 STEEM, musimy wydać 1000 jednostek ALPHA na jednostkę STEEM. Dlatego stosunek jednostek tego ICO wynosi 1000. Ten stosunek jednostek jest umieszczony w polach min_unit_ratio i max_unit_ratio struktury danych smt_capped_generation_policy:

min_unit_ratio = 1000
max_unit_ratio = 1000

Specjalna nazwa konta, $ from, reprezentuje współtwórcę. Obsługiwana jest również opcja $ from.vesting, która reprezentuje saldo uprawnień rachunku $ from.

Dlaczego wskaźniki jednostkowe?

Dlaczego blockchain stosuje wskaźniki jednostek, a nie tylko określa ceny?

Odpowiedź brzmi, że można pisać definicje ICO, dla których cena jest źle określona. Na przykład:
• "$ from" nie występuje w token_unit.
• "$ from" występuje zarówno w token_unit, jak i steem_unit.
• Występuje kombinacja "$ from" i "$ from.vesting".
• Przyszłe rozszerzenie umożliwią nowe specjalne konta.

Wszystkie te definicje ICO mają stosunek jednostek, ale zdefiniowanie pojedynczej ilości do wywoływania "ceny" jest skomplikowane lub niemożliwe dla takich ICO.

Wskaźniki jednostkowe w interfejsach

W związku z powyższym pojęcie "ceny ICO" jest pojęciem wyłącznie na poziomie interfejsu użytkownika. Interfejsy, które zapewniają cenę ICO, powinny wykonać następujące czynności:

• Udokumentuj dokładną definicję "ceny" dostarczoną przez interfejs użytkownika.
• Zachowaj się dobrze dla patologicznych danych wejściowych, jak wyżej.
• Miej przycisk do przełączania między wskaźnikiem jednostki a ceną.

Ukryta pula finansowania FAQ

• P: Czy moje ICO powinno mieć limit?
• O: Niektóre osoby trzymają się z dala od nielimitowanych ICO z powodu postrzeganej "chciwości", lub chcą mieć zagwarantowaną niższą wartość graniczną w stosunku do procentu ich wkładu w ICO.

• P: Czy moja pula finansowania powinna być ukryta?
• O: Niektórzy ludzie lubią przejrzystość i pewność publicznej puli. Inni ludzie myślą, że ukryta pula wywołuje podniecenie i buduje popyt. Jedynym możliwym kompromisem jest opublikowanie przedziału, na przykład "ta pula ICO to od 1 mln do 10 mln STEEM".

• P: Jak mogę wyłączyć limit?
• O: Ustaw go tak, aby pułap występował powyżej STEEM_MAX_SHARE_SUPPLY.

Efektywny czas uruchomienia to czas, w którym tokeny stają się zbywalne. Występują dwie możliwości w zależności od czasu ujawnienia puli finansowania:

• Kiedy min_steem_units i hard_cap_steem_units są ujawniane przed
announced_launch_time, uruchomienie jest uruchomieniem na czas. Logika uruchamiania jest następująca i wykonywana przez łańcuch blokowy, jak tylko nadejdzie announced_launch_time, niezależnie od dalszych działań użytkownika.

• Kiedy min_steem_units i hard_cap_steem_units nie zostały wcześniej ujawnione, uruchomienie będzie opóźnione. Logika uruchomienia jest wykonywana przez łańcuch blokowy, gdy min_steem_units i hard_cap_steem_units zostały ujawnione.

• Jeśli uruchomienie jest opóźnione, wówczas każdy uczestnik może użyć smt_refund_operation aby odzyskać swój STEEM w dowolnym momencie po announced_launch_time, a przed wykonywana jest logika uruchamiania.

Przyczyny tego procesu są następujące:

• Ukryta pula finansowania nie jest publikowana natychmiast (taka jest definicja ukrytej puli).

• Publikowanie ukrytej puli jest działaniem, które musi być wykonane przez twórcę ICO (żadne działanie wymagające niepublicznej informacji nie może nastąpić automatycznie na łańcuchu blokowym).

• Jeśli twórca ICO nie reaguje, wtedy logika uruchomienia nigdy nie zostanie wykonana.

• W przypadku takiego złośliwego lub nie reagującego twórcy ICO, STEEM inwestorów w rzeczywistości zostałyby uwięzione na zawsze i nigdy nie otrzymali by żadnych tokenów.

• Aby zapobiec uwięzieniu STEEM w ten sposób smt_refund_operation jest wdrażany.

Uwaga: użytkownicy nie muszą używać smt_refund_operation; każdy indywidualny uczestnik musi wyrazić zgodę na otrzymanie zwrotu pieniędzy. Jeśli twórca ICO poda do wiadomości publicznej uzasadniony powód, żę nie opublikował ICO przed announced_launch_time, możliwe jest, że wszyscy/większość inwestorów dobrowolnie zdecyduje się nie używać smt_refund_operation. W takim przypadku uruchomienie będzie pojawiać się jak tylko twórca ICO opublikuje ukryte wartości zebranego finansowania.

Logika uruchomienia uważa, że wkład, po którym następuje refundacja, jest równoznaczny z brakiem wkładu. Dlatego też, gdy wystąpi opóźnienie w uruchomieniu ICO, każdy uczestnik może znajdować się dokładnie w jednym z dwóch następujących stanów:

• Uczestnik wykonał smt_refund_operation, otrzymał STEEM z powrotem i nie będzie uczestniczyć w ICO.

• Uczestnik nie otrzymał zwrotu pieniędzy i będzie uczestniczył w ICO. Możliwe jest, że opóźnione uruchomienie przekroczyło wartość min_steem_units w ogłoszonym czasie uruchomienia, ale następnie spada poniżej jego wartości min_steem_units jako wynik refundacji. W takim przypadku ICO nie wystąpi; będzie traktowane tak, jakby nigdy nie osiągnęło swojego min_steem_units.