samczsun: Ang seguridad ng crypto protocol ay nakasalalay sa aktibong muling pagsusuri

Ang bug bounty program ay isang pasibong hakbang, samantalang ang seguridad ay nangangailangan ng aktibong pagpapatupad.

May-akda: samczsun, Tagapagtatag ng Security Alliance, dating Research Partner ng Paradigm

Ngayon, may pagkakaisa na sa industriya na ang seguridad sa cryptocurrency ay dapat sundin ang tatlong mahahalagang hakbang: pagsusulat ng mga test case sa yugto ng development upang matukoy ang mga pangunahing error; masusing pagsusuri bago ang deployment sa pamamagitan ng audit at mga kumpetisyon; at pagtatatag ng bug bounty program upang gantimpalaan ang mga researcher na responsable sa pag-uulat ng mga bug upang maiwasan ang mga pag-atake. Ang paglaganap ng mga best practice na ito ay malaki ang nabawas sa bilang ng mga on-chain na bug, na nagtulak sa mga attacker na ituon ang pansin sa pagnanakaw ng private key, pag-atake sa infrastructure, at iba pang off-chain na bug.

Gayunpaman, kahit ang mga protocol na dumaan na sa masusing audit at may malalaking bug bounty ay paminsan-minsan pa ring nabibiktima ng mga hacker. Ang mga ganitong insidente ay hindi lamang nakakaapekto sa mismong protocol kundi pati na rin sa pundasyon ng tiwala sa buong ecosystem. Ang mga kamakailang pag-atake sa Yearn, Balancer V2, at ang mga insidente sa seguridad ng Abracadabra at 1inch ngayong taon ay nagpapakita na kahit ang mga matagal nang subok na protocol ay hindi ganap na ligtas. Maaari bang naiwasan ng crypto industry ang mga pag-atakeng ito? O ito ba ay isang hindi maiiwasang bahagi ng decentralized finance?

Madalas sabihin ng mga komentarista na ang mas mataas na bug bounty ay maaaring nagprotekta sa mga protocol na ito. Ngunit kahit hindi isaalang-alang ang realidad ng ekonomiya, ang bug bounty ay likas na isang pasibong hakbang sa seguridad, na inilalagay ang kapalaran ng protocol sa kamay ng mga white hat hacker, samantalang ang audit ay isang aktibong hakbang ng protocol para protektahan ang sarili nito. Ang pagtaas ng bug bounty ay hindi makakapigil sa mga pag-atake ng hacker, dahil ito ay parang pagtaya na mauuna ang white hat kaysa sa black hat na matuklasan ang bug. Kung nais talagang protektahan ng protocol ang sarili nito, kailangan nitong aktibong magsagawa ng re-audit.

Pondo ng Treasury at Total Value Locked (TVL)

Minsan, pumapayag ang mga hacker na ibalik ang karamihan ng ninakaw na pondo at mag-iiwan lamang ng maliit na bahagi (karaniwan ay 10%) bilang gantimpala. Sa kasamaang-palad, tinatawag ng industriya ang gantimpalang ito na "white hat bounty", na nagdudulot ng tanong: Bakit hindi na lang magbigay ang protocol ng katumbas na halaga sa pamamagitan ng bug bounty program upang maiwasan ang abala ng negosasyon? Ngunit ang ganitong pananaw ay nagkakalito sa pagitan ng pondong maaaring nakawin ng attacker at ng pondong maaaring gamitin ng protocol.

Kahit na sa unang tingin ay parang maaaring gamitin ng protocol ang parehong pondo para sa seguridad, ang protocol ay may legal na karapatan lamang sa sarili nitong treasury at hindi maaaring gamitin ang pondo ng mga user. Hindi rin malamang na bibigyan ng user ng ganitong karapatan ang protocol nang maaga; tanging sa oras ng krisis (halimbawa, kung kailangang pumili ng depositor sa pagkawala ng 10% o 100% ng kanilang deposito) ay papayagan nilang gamitin ng protocol ang kanilang pondo para sa negosasyon. Sa madaling salita, ang panganib ay lumalaki kasabay ng TVL, ngunit ang budget para sa seguridad ay hindi kayang sumabay dito.

Capital Efficiency

Kahit na sapat ang pondo ng protocol (halimbawa, may malaking treasury, malakas ang kita, o may ipinatupad nang security fee policy), mahirap pa ring magdesisyon kung paano wasto itong ilalaan para sa seguridad. Kung ikukumpara sa pamumuhunan sa re-audit, ang pagtaas ng bug bounty ay sa pinakamabuti ay napakababa ng capital efficiency, at sa pinakamasama ay nagdudulot ng maling insentibo sa pagitan ng protocol at ng mga researcher.

Kung ang bug bounty ay nakaayon sa TVL, kapag pinaghihinalaan ng researcher na lalaki ang TVL ng protocol at mababa ang tsansa ng pag-uulit ng bug, mas malamang na itago nila ang kritikal na bug. Sa huli, maglalagay ito ng researcher at protocol sa magkasalungat na posisyon at makakasama sa mga user. Ang simpleng pagtaas ng bounty para sa kritikal na bug ay hindi rin epektibo: Malaki ang bilang ng mga freelance researcher, ngunit kakaunti lamang ang may sapat na kakayahan at naglalaan ng oras upang maghanap ng bug sa mga komplikadong protocol. Ang mga elite na researcher na ito ay magtutuon lamang ng oras sa mga bounty na may pinakamalaking tsansa ng ROI. Para sa malalaking, matagal nang protocol, dahil palaging inaasahang binabantayan ito ng mga hacker at researcher, napakababa ng tsansa na may matuklasang bug, kaya kahit gaano pa kalaki ang bounty, hindi ito sapat upang mahikayat silang maglaan ng oras.

Samantala, mula sa pananaw ng protocol, ang bug bounty ay pondo na nakalaan para sa isang kritikal na bug lamang. Maliban na lang kung handang sumugal ang protocol na hindi magkakaroon ng kritikal na bug at itatago ang liquidity status mula sa mga researcher, hindi magagamit ang pondong ito para sa iba pang layunin. Sa halip na maghintay nang pasibo na may makadiskubre ng bug, mas mainam na gamitin ang parehong halaga para sa maraming re-audit sa loob ng ilang taon. Sa bawat re-audit, tiyak na makakakuha ng atensyon ng mga top researcher, hindi limitado sa isang bug lamang, at mapapanatili ang pagkakahanay ng interes ng researcher at protocol: kung ma-exploit ang protocol, pareho silang masasaktan ang reputasyon.

Mga Umiiral na Halimbawa

Sa software at financial industry, ang taunang audit ay isang napatunayang best practice at ang pinakamahusay na paraan upang matukoy kung handa ang isang kumpanya sa patuloy na nagbabagong banta. Ang SOC 2 Type II report ay ginagamit ng mga B2B client upang suriin kung may sapat na security control ang supplier; ang PCI DSS certification ay nagpapakita na may tamang hakbang ang kumpanya para protektahan ang sensitibong payment information; at ang gobyerno ng US ay nangangailangan ng FedRAMP certification para sa mga may access sa government information upang mapanatili ang mataas na antas ng seguridad.

Bagama't ang smart contract mismo ay immutable, ang operating environment nito ay hindi permanente. Maaaring magbago ang configuration settings sa paglipas ng panahon, maaaring ma-upgrade ang dependencies, at ang mga code pattern na dating itinuturing na ligtas ay maaaring mapatunayang may panganib. Ang protocol audit ay isang pagsusuri ng seguridad sa oras ng audit, hindi isang garantiya ng seguridad sa hinaharap. Ang tanging paraan upang i-update ang resulta ng pagsusuring ito ay ang magsagawa ng panibagong audit.

Pagsapit ng 2026, dapat gawing ika-apat na hakbang ng protocol security ang taunang audit sa crypto industry. Ang mga kasalukuyang protocol na may malaking TVL ay dapat magsagawa ng re-audit batay sa kanilang deployment; ang mga audit company ay dapat magbigay ng espesyal na serbisyo para sa kabuuang re-audit ng deployment; at ang buong ecosystem ay dapat magbago ng pananaw tungkol sa audit report—ito ay pagsusuri lamang ng seguridad sa isang tiyak na oras, maaaring mag-expire, at hindi isang permanenteng garantiya ng seguridad.