Hii ndiyo sababu kujua kusoma smart contract kunakuwa ujuzi muhimu katika crypto, hata kama wewe si developer.
Lengo si kujifunza Solidity kwa usiku mmoja. Audit kamili inahitaji ujuzi wa kiufundi wa kina zaidi: usanifu, mantiki ya biashara, mwingiliano kati ya contracts, usalama wa EVM, miito ya nje, uendeshaji wa storage, majaribio na mashambulizi ya kiuchumi. Kusoma functions chache kwenye Etherscan hakuchukui nafasi ya kazi hiyo.
Lengo ni dogo zaidi, na linapatikana kwa urahisi zaidi.
Mtumiaji wa kawaida anaweza tayari kuthibitisha anwani ya contract, kuona kama code yake iko wazi, kumtambua owner wake, kutafuta functions fulani nyeti, kuelewa nani anaweza kuziita functions hizo, kubaini mfumo wa roles, kuthibitisha kama supply inaweza kuongezeka na kugundua kama code inaweza kubadilishwa.
Usomaji huu hautajibu maswali yote.
Hata hivyo, unaweza kuibua maswali mazuri sana.
Na wakati mwingine, function moja tu inatosha kubadilisha kabisa uchambuzi wa token.
Anza na kile ambacho contract inaweza kufanya kweli
Smart contract si hati ya kisheria iliyojaa ahadi. Ni program inayotekelezwa na blockchain.
Kwenye Ethereum, ina anwani, huhifadhi data na hutoa functions. Baadhi ya functions husoma data hiyo tu. Nyingine huibadilisha transaction halali inapozita. Ethereum hivyo hueleza contract kama program inayoishi kwenye anwani maalum ya mtandao.
Ufafanuzi huu unaonekana wa kiufundi. Unakuwa rahisi zaidi kwa mfano.
Token contract inaweza kuwa na taarifa zifuatazo kwa msingi:
jina la token;
symbol;
supply yote;
salio la kila anwani;
kanuni za uhamishaji;
ruhusa za kiutawala;
mifumo inayoweza kuruhusu kuunda au kuharibu token.
Glossary yetu kamili ya crypto tayari inasaidia kupata dhana za wallet, multisig, vesting au conditional contracts. Hapa, tunahitaji kwenda hatua moja mbele: kuangalia kanuni moja kwa moja pale zinapotekelezwa.
Hatua ya kwanza: tafuta anwani halisi ya contract
Kabla hata ya kusoma code, lazima kwanza uchambue contract sahihi.
Ticker haitoshi kamwe.
Mtu yeyote anaweza kuunda token iitwayo USDT, PEPE, LINK au kutumia tena jina la mradi ambao bado haujazindua asset yake. Token mbili zinaweza kuwa na jina na symbol sawa kabisa, huku zikiwa zinadhibitiwa na contracts tofauti kabisa.
Taarifa muhimu ni anwani ya contract.
Kwenye Ethereum, inaonekana kama mfululizo mrefu unaoanza na 0x.
Kwa hakika, inapaswa kupatikana kutoka vyanzo kadhaa vinavyolingana:
tovuti rasmi ya mradi;
nyaraka zake;
block explorer inayotambulika;
na, ikiwezekana, links zilizochapishwa na timu kwenye channels zake rasmi.
Epuka mazoea ya kawaida ya kutafuta tu jina la token kwenye Google na kubofya contract ya kwanza inayoonekana kufanana.
Copy inaweza kuwa na ticker sawa.
Lakini si anwani sawa.
Baada ya kupata anwani, unaweza kuifungua kwenye Etherscan kwa Ethereum, au kutumia explorer inayolingana na blockchain husika. Kanuni ya jumla inabaki karibu sawa kwenye mitandao kadhaa ya EVM.
“Source Code Verified” ni kichujio cha kwanza
Kwenye Etherscan, fungua kichupo cha Contract.
Taarifa ya kwanza muhimu ni uthibitishaji wa code.
Developer anapothibitisha contract yake, Etherscan hukompile code ya chanzo iliyowasilishwa na kuthibitisha kama inalingana na bytecode iliyopo kwenye blockchain. Katika uthibitishaji sahihi, msomaji hupata toleo linalosomeka na binadamu la program linalolingana na contract iliyodeployiwa, pamoja na ABI yake na taarifa mbalimbali za compilation.
Hili ni muhimu sana.
Bila uthibitishaji huu, blockchain bado huwa na program hiyo. Lakini kinachoonekana hasa kwa msomaji ni bytecode iliyokusudiwa kwa EVM, ambayo si rahisi sana kuchambua kwa mkono.
Contract iliyothibitishwa hubadilisha kitu kinachofanana na mkusanyiko wa data za mashine kuwa files za Solidity zinazosomeka.
Hata hivyo, epuka kosa moja.
Verified haimaanishi audited.
Na audited haimaanishi haiwezi kushambuliwa.
Nyaraka za Ethereum kuhusu uthibitishaji wa smart contracts zinakumbusha kwamba uthibitishaji kimsingi huthibitisha uwiano kati ya code ya chanzo na bytecode iliyodeployiwa. Hauthibitishi kwamba mantiki ni salama.
Developer anaweza kuchapisha kikamilifu code ya contract yenye function inayoruhusu kuunda kiasi kisicho na kikomo cha token.
Code hiyo itakuwa verified.
Na hatari bado itakuwa halisi.
Uthibitishaji huleta uwazi.
Hautoi cheti cha tabia njema.
Kichupo cha Read Contract ni rafiki yako mkubwa
Asiye developer hatahitaji kuanza na files za Solidity.
Etherscan kwa kawaida hutoa interfaces mbili zinazoeleweka zaidi:
Read Contract
na
Write Contract.
Read Contract hukuruhusu kuona data za umma zinazotolewa na program bila kubadilisha blockchain wala kulipa gas. Write Contract ina functions zinazoweza kuanzisha transactions na hivyo kubadilisha hali ya contract.
Anza na Read.
Kwa ERC-20 ya kawaida, unaweza kupata functions kama:
name
symbol
decimals
totalSupply
balanceOf
owner
Maneno haya tayari hutoa taarifa nyingi.
name() hukupa jina.
symbol() ticker yake.
totalSupply() supply iliyoundwa wakati huo.
balanceOf(address) hukuruhusu kuuliza anwani ina token ngapi.
owner() inaweza kufichua anwani yenye mamlaka ya kiutawala ikiwa contract inatumia ownership model inayolingana.
Si lazima kuelewa kila mabano ya Solidity ili kutumia functions hizi.
Etherscan hubadilisha interface ya smart contract kuwa mfululizo wa sehemu za kujaza.
Ni karibu kama fomu.
Kuwa makini na decimals
Jambo moja huwaduwaza wanaoanza.
Unafungua totalSupply() na kuona:
1000000000000000000000000000
Bilioni moja za mabilioni?
Si lazima.
ERC-20 nyingi hutumia decimal places. OpenZeppelin kwa default hutumia decimal 18 katika implementation yake ya ERC-20. Interface ya wallet hugawa nambari kamili zinazotumiwa na contract kwa 10^18 ili kuonyesha kiasi kinachoeleweka.
Kwa hiyo:
1 000 000 000 000 000 000
inaweza kuwakilisha tu token 1 yenye decimal 18.
Kabla ya kutafsiri supply, thibitisha decimals().
Ni jambo dogo.
Linaepusha makosa makubwa ya kimantiki.
Sasa tafuta owner
Swali linalofuata ni muhimu zaidi:
nani anadhibiti contract?
Ikiwa function owner() ipo, ibofye.
Kawaida utapata anwani.
Inakili.
Fungua anwani hiyo.
Je, ni wallet ya mtu binafsi?
Smart contract nyingine?
Multisig?
Timelock?
Governance contract?
Anwani pekee haitoshi. Lazima ufuatilie hatua moja zaidi.
OpenZeppelin inaeleza Ownable kama mojawapo ya njia rahisi zaidi za access control: anwani moja huwekwa kuwa owner na functions zilizolindwa na utaratibu wa aina ya onlyOwner huwekwa kwa ajili yake.
Hili linaweza kuwa jambo la kawaida kabisa.
Timu wakati mwingine inahitaji kusimamia baadhi ya parameters, hasa mwanzoni mwa protocol.
Swali halisi linakuwa:
owner huyu ana mamlaka gani?
Owner anayeweza kubadilisha tu anwani ya metadata hana hatari sawa na owner anayeweza kufanya mint, kufreeze, kutaifisha, kubadilisha fees na kubadilisha code yote.
Kwa hiyo uwepo wa administrator hautoshi kuuhukumu wala kukutuliza.
Lazima usome mamlaka yake.
Tumia Ctrl+F: onlyOwner
Tunafika kwenye sehemu rahisi kwa kushangaza.
Kwenye kichupo cha Code, tumia search ya browser yako.
Andika:
onlyOwner
Utapata functions zilizowekwa kwa owner katika contracts zinazotumia convention hii.
Mfano wa kubuniwa:
function setFee(uint256 newFee) external onlyOwner
Hata bila kujua programming, sentensi hii inakuwa karibu kusomeka.
function setFee
function inaruhusu kubadilisha fees.
newFee
inapokea kiwango kipya cha fees.
external
inaweza kuitwa kutoka nje ya contract.
onlyOwner
ni owner pekee anayeweza kuitumia.
Umesoma sehemu ya smart contract.
Huhitaji kuelewa EVM inavyofanya kazi.
Sasa uliza swali sahihi: je, kuna kikomo kwa kiwango kipya cha fees?
Kwa mfano:
require(newFee <= 5)
inaweza kuonyesha kikomo cha 5, kulingana na jinsi asilimia inavyowakilishwa.
Bila kikomo kinachoonekana, function inaweza kuruhusu thamani kubwa zaidi, kulingana na mantiki iliyobaki.
Usihitimishe mara moja.
Fuatilia variable hiyo.
onlyOwner si mfumo pekee wa permissions
Miradi changamano mara nyingi hutumia roles.
Pia tafuta:
hasRole
onlyRole
DEFAULT_ADMIN_ROLE
MINTER_ROLE
PAUSER_ROLE
UPGRADER_ROLE
Majina hutofautiana.
OpenZeppelin hutoa access control inayotegemea roles ili accounts tofauti ziwe na majukumu tofauti: kuunda token, kusimamisha, kusimamia na kufanya operations nyingine.
Mara nyingi hii ni bora kuliko key moja inayodhibiti kila kitu kabisa.
Hata hivyo, bado lazima uangalie nani anashikilia roles hizo.
Mradi unaweza kutangaza:
“Ownership renounced”.
Inavutia sana.
Kisha ukaacha DEFAULT_ADMIN_ROLE yenye uwezo wa kumpa anwani mpya MINTER_ROLE.
Katika hali hiyo, kuachana na owner hakujibu swali halisi.
Mamlaka ya kweli iko kwingine.
Usitafute owner pekee. Tafuta permissions zote.
mint: je, token mpya zinaweza kuundwa?
Kwa token, utafutaji ulio wazi zaidi ni:
mint
Function ya mint kwa kawaida huunda units mpya.
Ethereum hutumia mfano huu katika nyaraka zake za kielimu: function ya mint inaweza kuongeza salio la mpokeaji, huku control ikiweka matumizi yake kwa owner.
Uwepo wa function ya mint si jambo la kutisha moja kwa moja.
USDC, stablecoins, reward systems, staking na blockchains zenye issuance iliyopangwa: miundo mingi halali inahitaji kuundwa kwa token mpya.
Swali ni:
nani anaweza kufanya mint?
Kiasi gani?
Kwa kanuni zipi?
Je, kuna supply ya juu?
Mint inatumiwa na mechanism ya kiotomatiki au na administrator?
Mradi unakuambia supply ya juu ni token milioni 100.
Contract ina:
mint(address to, uint256 amount) onlyOwner
na hakuna kikomo kilicho wazi.
Una swali la kuuliza.
Je, supply iliyoelezwa kwenye marketing imewekewa kikomo kweli kwenye kiwango cha contract?
Ikiwa ndivyo, iko wapi?
Kikomo kinaweza kuwekwa kwingine, katika extension ya ERC20Capped, variable ya MAX_SUPPLY au condition.
Kwa hiyo usisimame kwenye neno mint.
Tafuta constraint.
burn si bullish kila mara kama marketing inavyodai
burn huharibu token.
Neno hili linawavutia sana wawekezaji kwa sababu linaashiria supply inayopungua.
Lakini hata hapa, angalia nani anaweza kuchoma nini.
Je, mtumiaji anaweza kuchoma token zake mwenyewe tu?
Je, administrator anaweza kuchoma token za anwani nyingine?
Je, protocol inanunua token kweli kabla ya kuzichoma?
Au inaharibu tu sehemu ya token zilizotolewa hivi karibuni?
Economy inayounda token mpya milioni 100 kisha kuchoma milioni 20 bado ina inflation ya milioni 80.
Function hiyo inavutia.
Salio halisi la supply ni muhimu zaidi.
pause: kitufe cha dharura au mamlaka ya kati?
Tafuta:
pause
unpause
paused
OpenZeppelin hutoa rasmi mechanism ya ERC20Pausable inayoruhusu kusimamisha transfers, mint na burn wakati contract imeiunganisha na functions husika zimefungwa ipasavyo kwenye access control. Wazo hili linaweza kutumika kama kitufe cha dharura pindi dosari kubwa inapogunduliwa.
Huu ni mfano mzuri wa function inayoonekana ya kutuliza na ya kutia wasiwasi kwa wakati mmoja.
Ya kutuliza:
shambulizi linapoanza, timu inaweza kusimamisha mfumo ikiwezekana.
Ya kutia wasiwasi:
mtu ana mamlaka ya kusimamisha mfumo.
Uchambuzi sahihi si:
“pause = scam”.
Ni:
nani anaweza kuanzisha pause?
Key moja?
Multisig?
Governance mechanism?
Je, kuna timelock?
Nini hasa hutokea wakati wa pause?
Transfers zote?
Operations fulani tu?
Hii ndiyo tofauti kati ya kutambua function na kuelewa hatari.
blacklist, blocklist na freeze
Kisha tafuta maneno haya:
blacklist
blocklist
freeze
frozen
isBlocked
denylist
Yanaweza kufichua uwezo wa kuzuia anwani fulani.
Hata hivyo, hilo pekee halithibitishi tabia ya nia mbaya.
Baadhi ya stablecoins za kati hujumuisha kwa makusudi mechanisms za compliance zinazowezesha kufreeze anwani zinazohusishwa na sanctions au fedha zilizoibwa.
Lakini ikiwa ulifikiri unanunua asset iliyo censorship-resistant kabisa, function hii hubadilisha uchambuzi wako.
Code haisemi lazima:
“hiki ni kibaya”.
Inasema:
“haya ndiyo mamlaka yaliyopo”.
Ni wewe kuamua kama yanaendana na ahadi ya mradi.
Tafuta functions zinazobadilisha fees
Token fulani hukata tax kwenye transfers.
Tafuta:
fee
tax
setFee
setTax
buyTax
sellTax
marketingFee
liquidityFee
setFees
Wakati mwingine unaweza kugundua kwamba contract inatofautisha ununuzi na uuzaji.
Kwa mfano, tax ya 2% inaweza kugharamia treasury.
Hakuna jambo la ajabu.
Tatizo linaonekana wakati administrator anaweza kubadilisha tax hii bila kikomo kinachofaa.
Token inaweza kufanya kazi kawaida leo, kisha kesho ikawa karibu haiuziki ikiwa tax kubwa sana inaweza kutumika.
Mbinu hii huonekana katika baadhi ya honeypots au token zenye nia mbaya.
Uwepo wa function ya setTax pekee si uthibitisho wa honeypot.
Hata hivyo, kutokuwepo kwa kikomo kunastahili kueleweka kabla ya kununua.
Vikomo vya transaction vinaweza pia kuwa mtego
Tafuta:
maxTx
maxTransaction
maxWallet
tradingEnabled
enableTrading
limits
cooldown
Functions hizi wakati mwingine hutumika kulinda uzinduzi dhidi ya bots au kuzuia mkusanyiko mkubwa wa token.
Pia zinaweza kumpa administrator udhibiti mkubwa sana wa biashara.
Kwa mfano, mradi unaweza kuweka ukubwa wa juu wa sale.
Angalia kama ukubwa huo unaweza kupunguzwa kiholela.
Mantiki hiyo hiyo inatumika kwa tradingEnabled.
Ikiwa owner anaamua wakati transfers zitakuwa huru, hilo linaweza kuwa na mantiki kabla ya uzinduzi.
Baada ya uzinduzi, swali linabadilika:
anaweza kuzizima tena?
excludeFromFee inastahili kuangaliwa
Tax inawahusu wawekezaji wote.
Isipokuwa anwani fulani.
Kwa nini?
Wakati mwingine hilo ni la kawaida kabisa: router, liquidity contract, treasury au components nyingine za kiufundi zinaweza kuhitaji utaratibu maalum.
Lakini whitelist ya wallets zilizopewa upendeleo pia inaweza kuunda faida kubwa.
Tafuta:
excludedFromFees
isExcludedFromFee
whitelist
isWhitelisted
Kisha tafuta jinsi orodha hiyo inavyoweza kubadilishwa.
Nani anaongeza anwani?
Nani anaiondoa?
Status hiyo inaruhusu nini?
Uchambuzi wa smart contract mara nyingi hufanya kazi kama uchunguzi: neno moja hukupeleka kwenye function, function hiyo hukupeleka kwenye anwani, na anwani hiyo hukupeleka kwenye contract nyingine.
Husomi kila kitu.
Unafuatilia mamlaka.
Tahadhari za kweli zimejificha kwenye permissions
Kufikia hapa, tayari unajua kusoma mengi zaidi ya bei kwenye CoinMarketCap.
Hata hivyo, kiini cha tatizo kinabaki: smart contracts za kisasa mara chache hufanya kazi zenyewe.
Zinarithi libraries.
Zinaita contracts nyingine.
Zinakabidhi baadhi ya functions.
Wakati mwingine zinadhibitiwa na administrators kadhaa.
Au zinaweza kubadilishwa na toleo jipya.
Hapa ndipo usomaji unakuwa wa kuvutia kweli.
owner anaweza kuwa multisig
Unabofya owner().
Anwani unayopata si wallet ya kawaida bali ni smart contract.
Hii si lazima iwe ngumu zaidi.
Contract hiyo inaweza kuwa multisig.
Multisignature huhitaji keys kadhaa ili kuthibitisha operation nyeti.
Hili ni muhimu kwa sababu hatari hubadilika sana.
Key moja ya administrator ikiathirika:
mtu mmoja anaweza kuchukua hatua.
Multisig ya 3-kati-ya-5:
mshambuliaji kwa kawaida lazima athibiti signatories wa kutosha kufikia threshold.
Hii si guarantee kamili. Signatories wanaweza kudhibitiwa na organisation moja. Devices zinaweza kuwa hazijalindwa vizuri. Threshold inaweza kuwa ndogo sana ikilinganishwa na mtaji unaosimamiwa.
Bref Crypto hivi karibuni ilionyesha mada hii kupitia uchambuzi wa mamlaka ya kiutawala ya USDT kwenye Tron. Mada hiyo haikuhusu key inayotoa ufikiaji wa moja kwa moja wa USDT zilizoko kwenye wallets zote. Ilikuwa inahusu udhibiti wa kiutawala wa contract yenyewe.
Hii ndiyo aina ya nuance inayoweza kupatikana kwa kusoma smart contract.
Timelock inaweza kubadilisha kabisa hatari
Sasa fikiria administrator anaweza kubadilisha function.
Sawa.
Je, anaweza kuibadilisha mara moja?
Au operation lazima isubiri saa 24, saa 48 au wiki moja?
Timelock huweka muda wa kusubiri kati ya kuratibu operation ya kiutawala na kuitekeleza.
Kwa mtumiaji, tofauti ni kubwa sana.
Key ya administrator isiyo na delay inaweza kubadilisha baadhi ya parameters karibu mara moja.
Kwa timelock ya wazi, waangalizi wanaweza wakati mwingine kuona mabadiliko yaliyopangwa kabla ya kuanza kutumika.
Hivyo wanapata muda wa kuchukua hatua.
Tafuta:
TimelockController
delay
minDelay
getMinDelay
schedule
execute
Ikiwa contract inatumia governance system, tafuta pia nani anaweza kupendekeza operation na nani anaweza kuitekeleza.
Usanifu uliogatuliwa si suala la idadi ya wallets pekee.
Ni suala la mamlaka na muda wa kusubiri.
“Ownership renounced” inaweza kuwa karibu haina maana
Sentensi hii huonekana mara kwa mara kwenye marketing ya token:
Ownership renounced.
Kawaida humaanisha owner amehamisha jukumu lake kwenda kwenye anwani isiyoweza kutumika au ametumia renounceOwnership().
Sawa.
Lakini kabla ya kushangilia, uliza maswali mengine matano.
Je, kuna AccessControl tofauti?
Admin wa proxy?
Jukumu la minter?
Jukumu la upgrade?
Function nyingine yenye privilege?
Ownership ya contract ni mfumo mmoja tu kati ya mifumo ya permissions.
Timu inaweza kitaalamu kuachana na jukumu la owner kwenye sehemu moja ya mfumo, huku ikiendelea kudhibiti contract nyingine inayoweza kubadilisha tabia halisi ya protocol.
Ndiyo maana utafutaji unapaswa kuhusisha mnyororo mzima wa udhibiti.
Neno “renounced” ni mwanzo wa uchunguzi.
Si hitimisho.
Angalia imports
Juu ya file ya Solidity mara nyingi kuna mistari kama:
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
au:
import "@openzeppelin/contracts/access/Ownable.sol";
Hata bila kuelewa Solidity, imports hizi hutoa dalili.
Contract inatumia components za nje.
Ethereum inahimiza matumizi ya libraries zinazotambulika badala ya kuandika upya kila mara mechanisms zilezile, hasa kwa tabia za kawaida kama administration au emergency pause.
OpenZeppelin inatumika sana.
Kuona library inayojulikana kwa kawaida hutia moyo zaidi kuliko implementation ya mkono kabisa ya function ya kawaida.
Lakini tena:
kutumia OpenZeppelin hakufanyi contract kuwa salama moja kwa moja.
Developer anaweza kuchukua component bora ya ERC-20 na baadaye kuongeza function hatari.
Kwa hiyo soma hasa kile ambacho mradi unaongeza au kubadilisha.
public, external, private, internal
Maneno machache ya Solidity yanatosha kukusaidia kusoma functions vizuri.
public
function inaweza, miongoni mwa mambo mengine, kuitwa kutoka nje.
external
ni sehemu ya interface inayoweza kuitwa kutoka nje.
private
inapatikana ndani ya contract iliyoiunda pekee.
internal
inaweza kutumiwa na contract hiyo na contracts fulani zinazoirithi.
Ethereum inaeleza kwa usahihi viwango hivi tofauti vya visibility katika nyaraka zake.
Jihadhari na mtego muhimu:
public haimaanishi lazima kwamba kila mtu anaweza kufanikiwa kutekeleza function.
Function inaweza kuwa public na kuwa na:
onlyOwner
au condition:
require(msg.sender == admin)
Visibility inakuonyesha function inaweza kuitwaje.
Access control inakuonyesha nani ameruhusiwa.
Taarifa hizi mbili lazima zisomwe pamoja.
view na pure kwa kawaida hazina wasiwasi mkubwa
Function yenye alama ya view huahidi kutobadilisha state ya contract.
Function ya pure haipaswi kusoma wala kubadilisha state.
Kwa uchambuzi wa kwanza, kwa kawaida zina kipaumbele kidogo kuliko functions zinazoweza kuandika kwenye contract.
Ethereum hutaja kwa mfano balanceOf() kama function ya kawaida ya view: huangalia salio.
Kinyume chake, function inayoweza kubadilisha parameter, kuhamisha asset, kuunda token au kubadilisha permission inastahili umakini zaidi.
Hii si kanuni kamili ya usalama.
Ni njia ya kupanga vipaumbele.
Hujui coding?
Anza kwa kuangalia nani anaweza kubadilisha kitu.
payable inamaanisha function inaweza kupokea ETH
Neno lingine muhimu:
payable.
Function ya payable inaweza kupokea ETH pamoja na call yake.
Hii si hatari kwa ufafanuzi.
NFT mint ya payable, uuzaji wa token au baadhi ya protocols za DeFi huhitaji hilo.
Lakini unapochunguza function ambayo mtumiaji lazima atume fedha, elewa inachofanya kabla ya kusign.
Web3 interfaces wakati mwingine hurahisisha experience kiasi kwamba tunasahau click ni transaction inayotumwa kwa program.
Elewa approve kabla ya kuangalia code ya kigeni
Wakati mwingine, hatari kubwa zaidi haitokani hata na function ya ajabu.
Inatokana na standard.
Kwenye ERC-20, approve(spender, amount) huruhusu anwani nyingine au smart contract kutumia kiasi fulani cha token zako kupitia mfumo wa allowance.
Hii ni muhimu kwa sehemu kubwa ya DeFi.
Kwa mfano, DEX lazima iweze kuhamisha token zinazohitajika kwa swap.
Lakini approval kubwa sana ikipewa contract isiyo sahihi inaweza kuhatarisha fedha husika.
Ndiyo maana transaction ya approve haipaswi kutafsiriwa kama:
“ninathibitisha tu kitu fulani”.
Unatoa permission.
Angalia:
ni token gani?
spender gani?
kiasi gani?
Approval isiyo na kikomo inaweza kubaki valid kwa muda mrefu baada ya interaction ya kwanza.
Hapa pia, kujua kusoma maneno tayari kunaboresha sana usalama.
Jihadhari na function ambayo jina lake linatuliza kupita kiasi
Majina ya functions huchaguliwa na developers.
Function iitwayo:
safeTransfer
si salama moja kwa moja.
Function:
protectUsers
si lazima iwalishe watumiaji.
Function:
renounceOwnership
inaweza kuwa imebadilishwa kwenye contract maalum.
Lazima uangalie inachotekeleza kweli.
Hili ni muhimu hasa katika scams zilizofichwa kwa makusudi.
Developer anaweza kuchagua majina yasiyo na madhara.
Code inayotekelezwa ni muhimu zaidi kuliko jina.
Contract kuu inaweza kuleta mantiki halisi kutoka kwingine
Unafungua token.
File kuu ina mistari 50.
Vizuri.
Isipokuwa inarithi contracts nyingine tano.
Mantiki iko kwingine.
Tafuta declaration:
contract MyToken is ERC20, Ownable, Pausable...
Neno is hapa linaonyesha inheritance.
Kwa hiyo sehemu ya tabia hutoka kwenye contracts zilizotajwa.
Etherscan kwa kawaida huonyesha files mbalimbali za contract iliyothibitishwa. Unaweza kutoka moja hadi nyingine.
Asiye developer si lazima asome maelfu ya mistari ya OpenZeppelin.
Lengo hasa ni kutambua:
ni sehemu gani ni standard;
ni sehemu gani ni maalum kwa mradi.
Mantiki iliyobinafsishwa mara nyingi inastahili umakini zaidi.
Events pia husimulia historia
Smart contracts zinaweza kutoa events zilizohifadhiwa kwenye logs.
Ethereum inaeleza kwamba events hizi huwezesha interfaces na applications kufuatilia mabadiliko yanayosababishwa na contract.
Kwa mtumiaji, hii huwa muhimu anapotaka kuthibitisha kama mamlaka fulani imetumika kweli.
Tafuta events kama:
OwnershipTransferred
RoleGranted
RoleRevoked
Paused
Unpaused
Upgraded
Majina hutofautiana kulingana na contracts.
Hivyo unaweza kuvuka swali:
“je, administrator anaweza kufanya hivi?”
na kuuliza:
“je, tayari amefanya hivyo?”
Contract inaweza kinadharia kuwa na emergency function ambayo haijawahi kutumika.
Nyingine inaweza kubadilisha parameters mara kwa mara.
Historia ya on-chain huleta muktadha.
Transactions za administrator wakati mwingine hueleza zaidi kuliko ahadi yake
Baada ya kumtambua owner au multisig, fungua anwani yake.
Angalia transactions zake.
Ni aina gani ya operations inazofanya?
Mabadiliko ya fees?
Mint?
Uhamishaji wa ownership?
Upgrades?
Harakati za mara kwa mara za treasury?
Uchambuzi wa smart contract hauishii kusoma code tuli.
Blockchain pia huonyesha jinsi mamlaka hiyo ilivyotumiwa.
Hii ni faida kubwa ya mfumo.
Documentation inaweza kuandikwa upya.
Transaction iliyothibitishwa hubaki kwenye historia.
Linganisha mamlaka na mawasiliano ya mradi
Hapa ndipo usomaji unakuwa wa kuvutia kwa mtazamo wa uandishi wa habari.
Je, contract inaendana na simulizi?
Mradi unasema:
“fixed supply”.
Je, contract inaruhusu mint ya ziada?
“Imegatuliwa kabisa”.
Nani anashikilia permissions muhimu?
“Haiwezekani kuwazuia watumiaji”.
Je, kuna blocklist?
“Immutable contract”.
Je, kuna upgrade mechanism?
“Jumuiya yenye mamlaka”.
Je, multisig ya timu bado ina mamlaka ya veto?
Si lazima utangaze uongo mara tu unapoona tofauti ya kwanza.
Usanifu changamano unaweza kuwa na sababu nzuri za kiufundi.
Lakini mkanganyiko huo unastahili maelezo.
Hapo ndipo smart contract inakuwa zaidi ya file la kiufundi.
Inakuwa chombo cha kuthibitisha ahadi.
Smart contract pia inaweza kutegemea data za nje
Code ya on-chain haijui moja kwa moja bei ya mafuta, matokeo ya mechi au GDP ya Marekani.
Inaweza kuhitaji oracle.
Bref Crypto hivi karibuni ilionyesha jinsi Chainlink sasa inavyosambaza baadhi ya data za kiuchumi za Marekani kwa smart contracts. Contract inaweza hivyo kuchukua hatua kulingana na data inayotoka nje ya dunia ya blockchain.
Hii inaleta swali jipya:
taarifa hiyo inatoka wapi?
Ukichambua lending platform, bei ya collateral inaweza kutegemea oracle.
Oracle yenye hitilafu inaweza kusababisha liquidations zisizo sahihi hata wakati mantiki ya smart contract inafanya kazi kama ilivyokusudiwa.
“Code inafanya kazi” si sawa kila mara na “mfumo unafanya kazi”.
Dependencies ni muhimu.
Proxy ni mtego ambao kila anayeanza anapaswa kuujua
Umeipata anwani.
Code imethibitishwa.
Owner anaonekana kuwa sahihi.
Hakuna function hatari ya mint.
Unafikiri umemaliza.
Kisha ujumbe mdogo unatokea kwenye Etherscan:
Proxy.
Wakati huo, uchambuzi wako unabadilika.
Proxy kwa kawaida hutenganisha anwani inayotumiwa na watumiaji na mantiki inayotekeleza program kwa kweli.
Kwa kurahisisha: unaingiliana na mlango uleule, lakini chumba kilicho nyuma ya mlango huo kinaweza kubadilishwa.
Kwa nini developers hutumia proxies
Smart contract ya kawaida iliyodeployiwa kwenye Ethereum haiwezi kubadilishwa kama Web2 application ya kawaida.
Hitilafu ikitokea, hakuna tu kitufe cha “replace file on the server”.
Upgradeability hujibu tatizo hili.
Kwa proxy, watumiaji huendelea kuingiliana na anwani thabiti huku calls zikikabidhiwa kwenye implementation contract yenye mantiki.
Wakati wa upgrade, implementation inaweza kubadilika.
Data zinaweza kubaki kwenye kiwango cha proxy.
OpenZeppelin inaeleza hasa Transparent na UUPS, ambazo ni architectures mbili za kawaida za upgradeability. Katika transparent proxy, administration ya proxy husimamia upgrades; katika UUPS, mantiki ya upgrade iko hasa kwenye implementation na inapaswa kulindwa na authorization mechanism.
Kwa developers, hii huleta flexibility kubwa.
Kwa mwekezaji, inaleta swali kubwa sana:
nani anaweza kubadilisha code?
Contract iliyoauditiwa leo inaweza kuwa tofauti kesho
Fikiria:
Version 1 imeauditiwa.
Hakuna mint isiyo na kikomo.
Hakuna fees za kupita kiasi.
Vizuri.
Hata hivyo, proxy ina administrator anayeweza kubadilisha implementation.
Miezi miwili baadaye, anaweka Version 2.
Mantiki mpya inaweza kuwa tofauti.
Audit ya contract ya kwanza si lazima itoshe tena.
Ndiyo maana OpenZeppelin inaeleza deployment ya upgradeable kuwa na angalau proxy logic na implementation, pamoja na mechanisms zinazoruhusu proxy kuelekeza kwenye implementation mpya wakati wa upgrade.
Hii si dosari moja kwa moja.
DeFi hutumia sana upgradeability kwa sababu kurekebisha bugs na kuendeleza protocol kunaweza kuwa muhimu.
Lakini protocol upgradeable na protocol immutable hazina trust model inayofanana kabisa.
Etherscan inakusaidia kupitia “Read as Proxy”
Kwa bahati nzuri, explorers za kisasa mara nyingi hugundua proxies.
Etherscan inaonyesha kwamba tabs za ziada zinazohusiana na proxy zinaweza kuonekana kwenye sehemu ya Contract. Interface yake pia hutofautisha code, functions za kusoma na functions za kuandika.
Unaweza kuona options kama:
Read as Proxy
Write as Proxy
na anwani ya implementation.
Kwa anayeanza, kanuni ni rahisi:
ikiwa Etherscan inaonyesha Proxy, usisome tu proxy contract ndogo. Tafuta pia implementation.
Hapo ndipo mantiki ya biashara kwa kawaida ilipo.
Tafuta upgradeTo na upgradeToAndCall
Kwenye mfumo upgradeable, majina yafuatayo yanastahili umakini:
upgradeTo
upgradeToAndCall
_authorizeUpgrade
implementation
ProxyAdmin
admin
OpenZeppelin hutumia hasa upgradeToAndCall katika mechanisms zake za sasa za proxy upgrade na inaeleza kwamba transparent proxies hutegemea ProxyAdmin, huku UUPS ikiweka authorization kwenye mantiki ya implementation.
Tena, function yenyewe si tatizo.
Mamlaka ndiyo tatizo.
Nani anaweza kuita upgrade?
Anwani ya mtu binafsi?
Multisig ya 2-kati-ya-3?
Multisig ya 5-kati-ya-8?
Governance?
Timelock ya siku saba?
Architectures hizi zina profiles za hatari tofauti sana.
Proxy inaweza hata kuficha viwango kadhaa
Protocol changamano inaweza kutumia:
proxy → implementation → contract nyingine → oracle → bridge → multisig.
Karibu DeFi.
Huu ndio wakati hasa wa kujua mipaka yako.
Mtu binafsi anaweza kufanya uchambuzi wa kiwango cha kwanza kwa busara.
Si lazima ajifanye anafanya professional audit ya contracts 50 zilizowekwa ndani kwa ndani.
Architecture inapokuwa changamano kupita kiasi, jibu sahihi si lazima liwe:
“lazima nielewe kila kitu”.
Linaweza kuwa:
“mfumo huu unazidi kiwango changu binafsi cha uchambuzi; nitaangalia audits, bug bounties, technical documentation na assessments huru”.
Kutambua mpaka huu ni ujuzi.
Audit hupunguza hatari, haiiondoi
Tafuta audits.
Lakini soma angalau:
nani aliyezifanya;
lini;
kwenye version ipi;
ni files zipi zilijumuishwa;
ni matatizo gani yalipatikana;
ni matatizo gani bado yako wazi;
kama contract imebadilishwa tangu wakati huo.
Badge ya “Audited by X” kwenye tovuti haitoshi.
Ripoti ndiyo muhimu.
Audit ya miaka miwili iliyopita kwenye Version 1 haifunikii moja kwa moja Version 4.
Protocol inaweza pia kuwa salama kiufundi lakini iwe katika hatari kiuchumi.
Lending contract inaweza kufanya kazi kama ilivyopangwa huku ikitumia oracle inayoweza kutumiwa vibaya.
Pool inaweza kufuata code yake na kupoteza fedha nyingi kwa sababu ya design mbaya ya kiuchumi.
Smart contract ni sehemu moja tu ya mfumo.
Exact Match na Similar Match: usizichanganye
Etherscan hutofautisha viwango kadhaa vya verification.
Exact Match inalingana kwa usahihi na code pamoja na taarifa za deployment zilizothibitishwa.
Similar Match hutegemea ulinganifu na bytecode inayofanana ambayo tayari imethibitishwa, na ina mipaka zaidi, hasa kwenye baadhi ya deployment parameters.
Etherscan kwa mfano inaonya kwamba constructor arguments tofauti zinaweza kubadilisha tabia halisi.
Kwa uchambuzi wa maana, angalia aina ya verification.
Badge ya rangi si mapambo tu.
Constructor inaeleza jinsi contract ilivyoanza
Tafuta:
constructor
Function hii hutekelezwa mara moja tu wakati wa deployment ya kawaida ya contract. Mara nyingi hutumika kuweka parameters za mwanzo: owner, supply ya awali au anwani mbalimbali. Ethereum hutumia hasa mfano wa constructor inayoweka owner = msg.sender.
Kwa nini hili ni muhimu?
Kwa sababu function ya mint inaweza kuwa imeondoka baada ya uzinduzi, huku supply yote ikiwa iliundwa kwenye constructor.
Au contract inaweza kuwa ilitoa roles muhimu kwa anwani fulani tangu mwanzo.
Kwenye upgradeable proxies, hali ni maalum zaidi: implementations kwa kawaida hutumia initialization function badala ya constructor ya kawaida ili kuanzisha state ya proxy.
Tafuta basi:
initialize
initializer
reinitializer
Initialization mbaya inaweza hata kuwa vulnerability kubwa katika baadhi ya mifumo ya upgradeable.
Kwa anayeanza, kumbuka hasa hili:
constructor au initialize = jinsi mamlaka ya mwanzo ilivyogawanywa.
delegatecall inastahili umakini maalum
Ukiona:
delegatecall
huenda uko kwenye eneo la kiufundi zaidi.
Mechanism hii kimsingi huruhusu code ya contract nyingine kutekelezwa huku ikitumia context ya storage ya contract inayoita. Proxies hutegemea kanuni hii.
Kwa asiye developer, si lazima ujaribu kuelewa mara moja maelezo yote ya EVM.
Badala yake, uliza:
call inakabidhiwa kwenye anwani gani?
Je, anwani hiyo inaweza kubadilika?
Nani anadhibiti mabadiliko hayo?
Haya ndiyo maswali ya kiuchumi yaliyo nyuma ya neno la kiufundi.
selfdestruct haina tena maana ile ya zamani
Guides za zamani za usalama mara nyingi zilipendekeza kutafuta selfdestruct kama red flag kubwa inayowezesha contract kuharibiwa.
Hali imebadilika kutokana na mabadiliko ya Ethereum protocol: tabia ya opcode imebadilishwa kwa kiasi kikubwa na upgrades za hivi karibuni. Kwa hiyo usitumie moja kwa moja kanuni za zamani bila kuzingatia version na mtandao husika.
Hata hivyo, Ethereum bado huweka matumizi ya selfdestruct miongoni mwa operations zinazobadilisha state inapofafanua restrictions za functions za view.
Huu ni ukumbusho mzuri wa jumla:
guide ya smart contracts ya mwaka 2020 inaweza kuwa imepitwa na wakati kiufundi mwaka 2026.
Usibofye Write Contract ili “kujaribu”
Kichupo cha Write Contract ni muhimu sana.
Pia kinaweza kuanzisha transaction halisi.
Etherscan inaeleza wazi kwamba operations za kusoma hazibadilishi blockchain, huku Write Contract ikiweza kutuma transaction inayohitaji signature ya wallet na ada za gas.
Kwa hiyo:
soma Read Contract kwa uhuru.
Uwe mwangalifu zaidi na Write Contract.
Usiunganishe wallet yenye fedha zako kuu kwa ajili ya kuchunguza tu.
Usijaribu function usiyoielewa.
Usisign ili kuona “kitakachotokea”.
Kwenye blockchain, udadisi unaweza usiwekwe nyuma.
ABI inaweza kusaidia kuelewa contract bila kusoma code yote
ABI, au Application Binary Interface, kimsingi inaeleza jinsi ya kuwasiliana na functions za umma za contract: majina yake, parameters, data types na values zinazorudishwa.
Etherscan inaonyesha kwamba inawezekana kuelewa sehemu kubwa ya interactions za contract kwa kusoma ABI, bila kuchambua kila mstari wa source code.
Hii ndiyo approach inayofaa kwa lengo letu.
Huhitaji kujua kuandika:
function transfer(address _to, uint256 _value)
ili kuelewa kwamba:
transfer
inahamishe token,
_to
ni anwani ya mpokeaji,
_value
ni kiasi.
Interface tayari inakutafsiria sehemu kubwa ya lugha hiyo.
Njia ya dakika 15 inatosha kwa kichujio cha kwanza
Sasa tuchukue token tusiyoijua.
Una dakika 15.
Huu ndio mpangilio nitakaotumia.
Dakika ya 1: anwani.
Thibitisha kwamba contract inaendana na token rasmi.
Dakika ya 2: uthibitishaji.
Code verified? Exact Match? Proxy?
Dakika ya 3 hadi 5: Read Contract.
Angalia:
owner
totalSupply
decimals
na functions za kiutawala zinazoonekana.
Dakika ya 6 hadi 8: tafuta kwenye code.
Ctrl+F:
onlyOwner
onlyRole
mint
pause
blacklist
fee
tax
maxTx
upgrade
Dakika ya 9 na 10: permissions.
Nani anashikilia roles?
Wallet rahisi?
Multisig?
Timelock?
Governance?
Dakika ya 11 na 12: proxy.
Je, contract inaweza ku-upgrade?
Implementation ni ipi?
Nani anaweza kuibadilisha?
Dakika ya 13 na 14: historia.
Je, administrator amewahi kutumia functions hizi?
Je, kumekuwa na upgrades au uhamishaji wa roles?
Dakika ya 15: ulinganifu.
Je, mamlaka yaliyoonekana yanaendana na kile mradi unachosema?
Hii si audit.
Ni ukaguzi wa msingi wa kiufundi.
Na tayari ni bora zaidi kuliko kununua kwa sababu logo ni nzuri.
Mfumo wa alama nyekundu, chungwa na kijani
Unaweza hata kupanga observations, bila kugeuza hili kuwa score ya kiotomatiki.
Vinavyotia moyo zaidi:
code imethibitishwa kwa usahihi;
matumizi ya standards zilizoandikwa kwa kina;
permissions zilizoelezwa wazi;
multisig iliyogawanywa vya kutosha;
timelock kwenye operations muhimu;
supply inayoendana na taarifa za umma;
vikomo vilivyo wazi kwenye functions nyeti;
audits zinazoendana na version ya sasa;
historia ya kiutawala inayolingana.
Vinavyohitaji uchunguzi zaidi:
proxy upgradeable;
uwezekano wa pause;
mint inayodhibitiwa;
blocklist;
taxes zinazoweza kusanidiwa;
contract mpya sana;
multisig yenye signatories wachache;
permissions kubwa za kiutawala.
Vipengele hivi vinaweza kuwa na sababu halali kabisa.
Vinavyotia wasiwasi sana bila maelezo mazuri:
mint ya kiholela iliyofichwa licha ya ahadi ya supply isiyobadilika;
taxes zinazoweza kubadilishwa kuwa viwango vya kupita kiasi;
uwezekano wa kuzuia uuzaji kwa kuchagua;
administrator aliyefichwa baada ya kudaiwa kuachana na udhibiti;
implementation ya proxy inayoweza kubadilishwa na wallet moja huku protocol ikijieleza kuwa immutable;
source isiyothibitishwa kwa mradi ambao tayari unaomba mtaji mkubwa;
mkanganyiko mkubwa kati ya documentation na code.
Hakuna kipengele kimoja kinachothibitisha moja kwa moja ulaghai.
Hata hivyo, contradictions kadhaa kwa pamoja hubadilisha kwa kiasi kikubwa tathmini ya kesi.
Smart contract haitakuambia kama token ni nafuu
Hiki ni kikomo cha msingi.
Unaweza kuchambua kikamilifu contract salama ya token iliyopanda thamani kupita kiasi.
Smart contract haijibu:
FDV ni ya busara?
Unlocks zitasababisha dilution kwenye soko?
Timu inaweza kujenga product?
Demand ipo?
Token inakamata thamani ya kiuchumi?
Kwa hayo, lazima urudi kwenye tokenomics, mapato, watumiaji, wawekezaji na liquidity.
Uchambuzi wetu wa awali wa tokenomics na contract kwa hiyo ni layers mbili zinazokamilishana.
Tokenomics: nani atapokea token na lini?
Smart contract: token hizo zinafuata kanuni gani na nani anaweza kuzibadilisha?
Mwekezaji makini anahitaji yote mawili.
Code pia haitakuambia kama timu itadanganya kesho
Hata contract immutable iliyoandikwa kikamilifu haihakikishi mafanikio ya mradi.
Timu inaweza kutoweka.
Frontend inaweza kuathiriwa.
Oracle ya nje inaweza kushindwa.
Bridge inaweza kudukuliwa.
Liquidity inaweza kutoweka.
Soko linaweza kuacha product.
Smart contract si kampuni nzima.
Ni moja tu ya sehemu zinazoweza kuthibitishwa kwa urahisi zaidi.
Hilo pekee ni jambo la kushangaza.
Katika finance ya jadi, mtu binafsi hawezi kufungua software ya ndani ya benki na kujihakikishia mwenyewe functions za kiutawala zilizopo.
Kwenye crypto, sehemu ya mfumo wa fedha inaweza kuonekana moja kwa moja.
Inachohitajika ni kuangalia.
Kusoma contract hubadilisha zaidi maswali unayouliza
Huenda huu ndio ujuzi halisi.
Kabla:
“Token hii inaweza kupanda mara 10?”
Baada ya dakika chache kwenye smart contract:
“Nani anaweza kuongeza supply yake?”
“Nani anaweza kusimamisha transfers?”
“Je, anwani hii ya administrator ni multisig?”
“Kwa nini kuna UPGRADER_ROLE?”
“Je, contract inayowasilishwa kuwa immutable ni proxy kweli?”
“Kikomo cha tax kimeandikwa kwenye code?”
“Nani anaweza kuongeza anwani kwenye blacklist?”
Haya ni maswali bora.
Hayatabiri bei.
Yanapunguza asymmetry ya taarifa.
Kusoma smart contract, mwishowe, si kusoma code
Si mwanzoni.
Ni kusoma mamlaka.
Nani anaweza kuunda?
Nani anaweza kuharibu?
Nani anaweza kuhamisha?
Nani anaweza kuzuia?
Nani anaweza kubadilisha?
Nani anaweza kuchukua nafasi ya program?
Na ni watu wangapi wanahitajika kufanya hivyo?
Ukishapata majibu haya, yaliyobaki huwa wazi zaidi.
Mradi unaweza kukubali kabisa model ya kati.
Stablecoin inaweza kuhitaji mechanisms za compliance.
DeFi platform inaweza kuhifadhi kitufe cha dharura.
Protocol changa inaweza kubaki upgradeable kabla ya kuhamisha hatua kwa hatua udhibiti zaidi kwa governance yake.
Hakuna chaguo kati ya hayo lililo baya moja kwa moja.
Kinachokuwa tatizo ni mfumo kuwa na udhibiti mkubwa kuliko unavyoashiriwa na mawasiliano yake.
Blockchain ina sifa muhimu katika hali hii.
Marketing inaweza kusema “trustless”.
Smart contract yenyewe inatoa anwani ya admin.
Reflex ya kubaki nayo
Wakati mwingine token inapokuvutia, usianze na chart yake pekee.
Copy anwani yake.
Fungua explorer.
Bofya Contract.
Thibitisha code.
Fungua Read Contract.
Tafuta owner.
Kisha tafuta maneno machache.
mint.
owner.
onlyRole.
pause.
blacklist.
fee.
upgrade.
Huenda usielewe kila kitu.
Si tatizo.
Lengo si kushindana na auditor wa Solidity.
Lengo ni kutokuwa kipofu kabisa mbele ya program ambayo unakaribia kukabidhi fedha zako.
Kwenye soko ambalo interface maridadi inaweza kuficha layers kadhaa za smart contracts, ujuzi huu unakuwa karibu wa msingi sawa na kujua kuthibitisha anwani kabla ya kufanya transfer.
Smart contract haifanyi kuwa rahisi kwa sababu hujui Solidity.
Lakini sehemu kubwa ya mamlaka muhimu inaweza kufanywa isomeke.
Na mara nyingi, code haihitaji kukuambia kama mradi ni “mzuri”.
Inatosha kukuonyesha nani anaweza kubadilisha kanuni baada ya wewe kuingia.
Kwa ufupi
Asiye developer anaweza tayari kujifunza mengi kutoka kwenye smart contract bila kuchambua mantiki yake yote. Anwani sahihi, hali ya uthibitishaji wa code, owner, roles za kiutawala, functions za mint, pause, blacklist, kubadilisha fees na mechanisms za upgrade ni kichujio chenye nguvu cha kwanza.
Jambo muhimu zaidi linabaki kuwa access control. Function nyeti si lazima iwe hatari ikiwa matumizi yake yamewekewa kikomo na multisig, governance au timelock inayofaa. Kinyume chake, wallet moja rahisi yenye mamlaka mengi huwakilisha trust model iliyo katikati zaidi.
Proxy contracts zinahitaji umakini maalum. Anwani inayotumiwa na watumiaji inaweza kukabidhi mantiki yake kwa implementation inayoweza kubadilishwa. Kwa hiyo lazima utambue implementation na entity iliyoruhusiwa kufanya upgrades.
Mwisho, code iliyothibitishwa si audit wala guarantee. Etherscan hukuwezesha kuthibitisha kwamba code iliyochapishwa inalingana na program iliyodeployiwa; haihakikishi kwamba program hiyo haina vulnerability.
