Постоји проблем - тешко је генерисати случајни број у децентрализованој мрежи. Скоро сви блок ланци су се већ сусрели са овим. Заиста, у мрежама у којима нема поверења између корисника, стварање неоспорног случајног броја решава многе проблеме.
У овом чланку ћемо вам рећи како смо успели да решимо проблем користећи игре као пример. Први од њих је био . За развој нам је био потребан генератор случајних бројева.
У почетку смо планирали да генеришемо број на основу информација из блоцкцхаина. Међутим, тада је постало јасно: број се може манипулисати, што значи да решење није прикладно.
Смислили смо решење: користите шему урезивање-проширивање. Сервер је погодио број од 1 до 5, додао му со, а затим хеширао резултат користећи . Сервер је унапред применио паметни уговор са већ сачуваним бројем. Испоставило се да се игра своди на то да корисник погоди број скривен хешом.
Играч се кладио, а сервер је послао скривени број и „сол“ паметном уговору. Једноставно речено, открио је карте. Након тога, сервер је проверио бројеве и одлучио да ли је корисник победио или изгубио.
Ако сервер није послао број или „сол“ на верификацију, корисник је победио. У овом случају, за сваку игру је било потребно унапред применити паметни уговор и укључити потенцијалне добитке у њега. Испоставило се да је то незгодно, дуготрајно и скупо. У то време није било другог сигурног решења.
Недавно је Традисис тим предложио додавање функције у Вавес протокол рсаВерифи(). Проверава валидност РСА потписа на основу јавног и приватног кључа. Као резултат тога, функција је додата.
Развили смо три игре: , и . Сваки од њих имплементира технологију случајних бројева. Хајде да схватимо како то функционише.
Хајде да погледамо генерисање случајног броја користећи Риде он Вавес као пример. Паметни уговор се може пронаћи .
Идите на картицу Скрипта и изаберите Декомпилирано. Видећете код паметног уговора (ака скрипта).
Шифра паметног уговора садржи скуп функција. Они који су означени као @Цаллабле могу се покренути помоћу Трансакције позивања. Заинтересовани смо за две функције: Кладим и повући:
- функ бет (плаиерЦхоице)
- фунц повући(гамеИд,рсаСигн)
1. Корисник бира дужину сегмента и величину опкладе.
2. Клијент креира функцију опкладе. За слику изнад то би било опклада ("50").
3. Клијент шаље Инвоцатион трансакцију на адресу паметног уговора (броадцаст ИнвоцатионТк). Трансакција садржи функцију опкладе као параметар позива. То значи да трансакција Инвоцатион покреће извршење функције опкладе (избор: Стринг) на паметном уговору.
4. Размотрите функцију опкладе:
@Callable(i)
func bet (playerChoice) = {
let newGameNum = IncrementGameNum()
let gameId = toBase58String(i.transactionId)
let pmt = extract(i.payment)
let betNotInWaves = isDefined(pmt.assetId)
let feeNotInWaves = isDefined(pmt.assetId)
let winAmt = ValidateBetAndDefineWinAmt(pmt.amount, playerChoice)
let txIdUsed = isDefined(getString(this, gameId))
if (betNotInWaves)
then throw ("Bet amount must be in Waves")
else if (feeNotInWaves)
then throw ("Transaction's fee must be in Waves")
else if (txIdUsed)
then throw ("Passed txId had been used before. Game aborted.")
else {
let playerPubKey58 = toBase58String(i.callerPublicKey)
let gameDataStr = FormatGameDataStr(STATESUBMITTED, playerChoice, playerPubKey58, height, winAmt, "")
ScriptResult(WriteSet(cons(DataEntry(RESERVATIONKEY, ValidateAndIncreaseReservedAmt(winAmt)), cons(DataEntry(GAMESCOUNTERKEY, newGameNum), cons(DataEntry(gameId, gameDataStr), nil)))), TransferSet(cons(ScriptTransfer(SERVER, COMMISSION, unit), nil)))
}
}Функција уписује нову игру у стање паметног уговора. Наиме:
- Јединствени идентификатор за нову игру (ид игре)
- Стање игре = СУБМИТТЕД
- Избор играча (дужина сегмента 50)
- Јавни кључ
- Потенцијални добици (у зависности од опкладе играча)
Овако изгледа запис података у блокчејну (кључ-вредност):
{
"type": "string",
"value": "03WON_0283_448t8Jn9P3717UnXFEVD5VWjfeGE5gBNeWg58H2aJeQEgJ_06574069_09116020000_0229",
"key": "2GKTX6NLTgUrE4iy9HtpSSHpZ3G8W4cMfdjyvvnc21dx"
}"Кључ" (кључ) - ИД игре Нова игра. Преостали подаци се налазе у реду поља „вредност“. Ови уноси се чувају на картици Датум паметни уговор:
5. Сервер „гледа“ паметни уговор и проналази послату трансакцију (нова игра) користећи блоцкцхаин Апи. ИД игре нове игре је већ забележен у блокчејну, што значи да се више не може мењати или утицати
6. Сервер генерише функцију повлачења (гамеИд, рсаСигн). На пример, овако:
withdraw ("FwsuaaShC6DMWdSWQ5osGWtYkVbTEZrsnxqDbVx5oUpq", "base64:Gy69dKdmXUEsAmUrpoWxDLTQOGj5/qO8COA+QjyPVYTAjxXYvEESJbSiCSBRRCOAliqCWwaS161nWqoTL/TltiIvw3nKyd4RJIBNSIgEWGM1tEtNwwnRwSVHs7ToNfZ2Dvk/GgPUqLFDSjnRQpTHdHUPj9mQ8erWw0r6cJXrzfcagKg3yY/0wJ6AyIrflR35mUCK4cO7KumdvC9Mx0hr/ojlHhN732nuG8ps4CUlRw3CkNjNIajBUlyKQwpBKmmiy3yJa/QM5PLxqdppmfFS9y0sxgSlfLOgZ51xRDYuS8NViOA7c1JssH48ZtDbBT5yqzRJXs3RnmZcMDr/q0x6Bg==")7. Сервер шаље Инвоцатион трансакцију паметном уговору (броадцаст ИнвоцатионТк). Трансакција садржи позив формираној функцији повлачења (гамеИд, рсаСигн):
Функција садржи ИД игре нова игра и резултат РСА потписивања јединственог идентификатора са приватним кључем. Резултат потписа је непромењен.
Шта ово значи?
Узимамо исту вредност (ид игре) и примењујемо метод РСА потписа на њу. Увек ћемо добијати исти резултат. Овако функционише РСА алгоритам. Коначним бројем се не може манипулисати, пошто ИД игре и резултат примене РСА нису познати. Бирање броја је такође бесмислено.
8. Блоцкцхаин прихвата трансакцију. Покреће функцију повлачења (гамеИд, рсаСигн)
9. Унутар функције повлачења долази до повлачења ГенератеРандИнт функције (ИД игре, рсаСигн). Ово је генератор случајних бројева
# @return 1 ... 100
func GenerateRandInt (gameId,rsaSign) = {
# verify RSA signature to proof random
let rsaSigValid = rsaVerify (SHA256, toBytes(gameId), rsaSign, RSAPUBLIC)
if (rsaSigValid)
then {
let rand = (toInt(sha256(rsaSign)) % 100)
if ((0 > rand))
then ((-1 * rand) + 1)
else (rand + 1)
}
else throw ("Invalid RSA signature")
}ред - и постоји случајни број.
Прво се узима стринг, који је резултат РСА потписа ИД игре приватни кључ (рсаСигн). Затим хеширан са СХА-256 (сха256(рсаСигн)).
Не можемо предвидети исход потписа и накнадног хеширања. Стога је немогуће утицати на генерисање случајног броја. Да бисте добили број у одређеном опсегу (на пример, од 1 до 100), користите функцију конверзије тоИнт и %100 (слично ).
На почетку чланка смо споменули функцију рсаВерифи(), који вам омогућава да проверите валидност РСА потписа са приватним кључем у односу на јавни. Ево дела ГенератеРандИнт(гамеИд,рсаСигн):
rsaVerify (SHA256, toBytes(gameId), rsaSign, RSAPUBLIC)Јавни кључ РСАПУБЛИЦ и стринг рсаСигн се прослеђују на улаз. Потпис се проверава за валидност. Број се генерише ако је провера успешна. У супротном, систем сматра да потпис није валидан (Инвалид РСА сигнатуре).
Сервер мора да потпише ИД игре приватним кључем и пошаље важећи Рса потпис унутар 2880 блокова. Параметар се конфигурише приликом примене паметног уговора. Ако се ништа не догоди у предвиђеном времену, корисник побеђује. У овом случају, награду морате сами послати на вашу адресу. Испоставило се да „серверу није исплативо да вара“, јер то доводи до губитка. Испод је пример.
Корисник игра . Изабрао сам 2 од 6 страна коцке, опклада је 14 ТАЛАСА. Ако сервер не пошаље важећи РСА потпис паметном уговору у наведеном времену (2880 блокова), корисник ће узети 34.44 ВАВЕС.
За генерисање бројева у игрицама користимо пророчиште - екстерни систем без блокова. Сервер врши РСА потпис ИД-а игре. Паметни уговор проверава валидност потписа и одређује победника. Ако сервер не пошаље ништа, корисник аутоматски побеђује.
Ово је метода поштеног генерисања, јер је манипулација технички немогућа. Све Традисис игре раде на основу описаног алгоритма. Овако функционишу блокчејн игре. Све је транспарентно и проверљиво. Нема аналога таквог система ни у једном другом блокчејну. Ово је фер случајност.
Извор: ввв.хабр.цом