Karagdagang impormasyon mula sa SmartBillions team
Ang unang contract ay idinisenyo upang i-optimize ang karanasan ng mga user.
Pinagana ng contract ang withdraw ng premyo ng lottery hanggang isang buwan pagkatapos ng draw sa pamamagitan ng pagtatabi ng history na nasa 163840 block hashes (hashes[]), na kung saan mas mahaba kaysa sa default history na 256 hashes na available sa pamamagitan ng standard opcodes.
At sa parehong panahon, binawasan ng inisyal na contract ang partisipasyon ng player sa halagang pag-update sa database sa pamamagitan ng pag-rerequire ng update na pinakamataas sa 10 hashes, na tumutugon sa isang uin256 integer (5000 gas). Kung ang lottery ay magpatakbo ng maraming bets higit sa 1 bet / 10 blocks, ang player ay magtatabi ng database ng hashes ng nasa petsa nang walang aktibong partisipasyon ng admin.
Kung sakaling ang frequency ay mas maliit ang admin ay kailangang patakbuhin ang putHashes(kasama ng argument 25) function kahit na isang beses sa isang oras.
Ang admin ay pumalpak na gawin ito noong hackathon at ang frequency ng bets ay mas maliit kaysa sa inasahang produksyon ng environment.
Ang karagdagang problema ay ang pagsisimula ng database ng hashes,na walang tibay na pinakinabangan sa unang period na tatlompung araw, dahil sa oras ng pagawa ng marker ng hash (hash >> 240) ay isinet sa current na period at ang getHash function ay pumalpak na madetect na ang hash ay hindi nasimulan g maayos.
Ito ang nag-udyong sa exploit ng pagset ng bet sa 000000 (or 000001 ) at naghihintay sa 256 blocks o higit pa hanggang sa subukan ng contract na basahin ang draw hash mula sa database sa halip na short term memory na nakaimbak sa opcodes.
Nagdesisyon kaming gawin ang players na responsable para sa maintenance ng database ng hashes sa bagong contract. Kung ang frequency ng bets ay mananatiling mataas sa 1 bet / 10 block amg cost ng lottery para sa mga players ay mananatili kung ano ito. At kung sakaling ang bumagsak ang frequency, ang players ay kailangang magtabi ng mas maraming impormasyon tungkol sa history ng draws sa database (hanggang 25*10 hashes, 25 na uint256 integers). Kung sakaling ang frequency ng bets ay bumagsak mababa sa 1 bet / 250 hashes ang player ay kailangang kolektahin ang resulta sa 256 blocks mula sa draw block. Kung ang draw block hash ay hindi naitabi sa database ng hashes at ang player ay hindi nagkolekta ng resulta sa 256 blocks pagkatapos ng draw, ang bet ay mawawala ( ibabalik ng nakaraang contract ang bet value).
Ang solusyon na ito ang gagawa sa karanasan ng user maging mas problemado ngunit poprotekta sa investors laban sa pagbabalewala ng admin.
Kasama ng iba pang pagbabago ang pagtatama ng order ng transaksyon sa transferFrom function, ang pagbabago sa pagsisimula ng database ng hashes at modipikasyon ng hotStore function upang payagan ang kahit na sinu na magdeposit ng pondo sa contract at alisin ang mga pondong ito kinalaunan.
Ang bagong contract ay naideploy na. At ang admin ay pinalitan.
Magsisimula ulit kaming maglagay ng pondo sa contract.
Ang withdrawal ng admin ay posible sa coldStore function.
function coldStore(uint _amount) external onlyOwner
{
houseKeeping();
require(_amount > 0 && this.balance >= (investBalance * 9 / 10) + walletBalance + _amount);
if(investBalance >= investBalanceGot / 2){ // additional jackpot protection
require((_amount <= this.balance / 400) && coldStoreLast + 4 60 24 * 7 <= block.number);
}
msg.sender.transfer(_amount);
coldStoreLast = block.number;
}
Ang linyang ito:
require(_amount > 0 && this.balance >= (investBalance * 9 / 10) + walletBalance + _amount);
ay gumagarantiya ng ang admin ay hindi pwedeng magwithdraw ng mas maraming pondo higit: sa 90% ng mga pondo na ininvest sa panahon ng ICO plus ang pondo sa mga wallet na naghihintay na mawithdraw (kasama rito ang mga hindi bayad na premyo dahil sa kawalan mg pondo sa contract; gayunman ang mga premyo ay dapat i- claim ng won() function dati pa, kung hindi ang mga premyo ay hindi kilala ng contract).
Mayroon ding importanteng adisyunal na limit na ang withdraw amount ay kailangang mas maliit sa 0.25% ng jackpot at ang fraction na ito ay hindi pwedeng i-withdrawn ng mas madalas sa bawat pitong araw (4*60*24*7 blocks).
Ang adisyunal na limit ay tinalikdan kung 50% ng investors ay magpasyang hindi na mag-invest.
Ang adisyunal na limit ay nangangahulugan na kung mayroong malaking lottery win na naghihintay ngunit ang nanalo ay hindi pa nagkokolekta na resulta, kung gayon ang admin ay maaaring tumakbo kasama ang 0.25% ng current jackpot, na nag-iiwan ng 99.75% ng jackpot na mananatiling nasa contract. Sa makatuwid ang panganib na ito may neglible na epekto sa nakolektang pondo ng winner. Ang regular na withdraw na 0.25% bawat linggo ng admin upang i-promote ang lottery ay isang inaasahang ugali.
Ang bagong contract ay handa na online:
https://etherscan.io/address/0x103c2c150a2dbcc277ee084c59881978060c8c22ito ay pinapanatiling updated at subok ng development team at bago ipahayag ang bagong Hackathon.
