-
Notifications
You must be signed in to change notification settings - Fork 21
/
Глава 07 - Пример: Rewards
49 lines (36 loc) · 6.71 KB
/
Глава 07 - Пример: Rewards
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
Глава 7 - Пример: rewards
Следующим по сложности CC контрактом, является CC контракт вознаграждения. Он был предназначен для того, чтобы зацепить то, что большинство людей любят в мастернодах, и больше ничего другого, а именно - вознаграждение!
Идея в том, чтобы позволить людям запирать средства на какой-то промежуток времени и получать дополнительное вознагрждение. Желательно так же поддерживать больше чем один план вознаграждения и позволять настраивать детали плана. Один неожиданный поворт заключается в том, что кто угодно должен иметь возможность разблокировать средства тогда, когда они находятся на запирающем адресе. Причина для этого заключается в желании поддеривать SPV сервера и если запирание может быть осуществленно через обычную sendrawtransaction, требуется полная нода для разблокировки. Разрешая разблокироку любому, становится возможным иметь специальную ноду, которая разблокирует все заблокированные средства когда они к этому готовы. Таким образом, с точки зрения пользователя, он запирает средства и они возвращаются обратно на его кошелек после "созревания".
Приведенные выше требования подводят нас к использованию глобального СС адреса для запирания средств в контракте наград. Это позволяет любому правильно подписать разблокировку, но, конечно этого недостаточно, нам требуется быть уверенными в том, что, они следуют всем условиям разблокировки. Прежде всего тому, что средтва возвращаются на адрес блокировки.
Четыре настраивающихся аспекта для плана вознаграждения:
APR, minseconds, maxseconds, mindeposit
Это позволяет устанавливать различный размер APR (Annual percentage rate - годовая процентная ставка) для каждого плана (до 25%, все что выше становится неразумным), минимальное время на которое средства должны быть заперты, максимальное время в течение которого они зарабатывают вознаграждение и минимальная сумма для внесения.
Таким образом транзакция которая создает план вознаграждения будет иметь все эти аттрибуты и помещается в данные OP_RETURN. Все другие вызовы будут ссылаться на id транзакции создания плана и наследовать эти параметры из транзакции создания. Это означает, что достаточно важная проверка - убедиться в том, что id транзакции создания плана - валидный id.
Поскольку может случиться так, что изначальное финансирование будет израсходованно, есть необходимость в способе дополнительного пополнения плана вознаграждения.
Наличие нескольких возможных планов вознаграждения означает, что крайне полезно иметь rpc вызовы для получения информации о них. Отсюда: rewardslist возвращает лист id транзакций созданных планов вознаграждения и rewardsinfo <txid> возвращает информацию о конкретном плане вознаграждения.
Запирающая транзакция отправляет средства на адрес СС вознаграждения, вместе с обычной (маленькой) транзакцией на адрес на который должна осущесвиться разблокировка. Это позволяет проверить правильность разблокировки.
Все эти вещи реализованы в rewards.cpp, с кодом валидаций в 200 строк и общим размером около 700 строк. Больше чем faucet, но большая часть это не консенсусный код для создания правильных транзакций. Для того, чтобы упростить проверку конкретные позиции для vin и vout были определены как имещющие требуемые конкретные значения:
createfunding
vins.*: normal inputs
vout.0: CC vout for funding
vout.1: normal marker vout for easy searching
vout.2: normal change
vout.n-1: opreturn 'F' sbits APR minseconds maxseconds mindeposit
addfunding
vins.*: normal inputs
vout.0: CC vout for funding
vout.1: normal change
vout.n-1: opreturn 'A' sbits fundingtxid
lock
vins.*: normal inputs
vout.0: CC vout for locked funds
vout.1: normal output to unlock address
vout.2: change
vout.n-1: opreturn 'L' sbits fundingtxid
unlock
vin.0: locked funds CC vout.0 from lock
vin.1+: funding CC vout.0 from 'F' and 'A' and 'U'
vout.0: funding CC change
vout.1: normal output to unlock address
vout.n-1: opreturn 'U' sbits fundingtxid
Рекомендуется создавать такое распрделение vin/vout для каждого CC контракта чтобы быть уверенным в том, что rpc вызовы создающие транзакцию и код валидации имеют определенный набор ограничений которые можно проверить.