ពាណិជ្ជករបាត់បង់ 26 លានដុល្លារនៅក្នុង ezETH Tokens: ប្រព័ន្ធផ្សព្វផ្សាយបន្ទោសអ្នកប្រើប្រាស់, Hacker ហៅកំហុស ERC-20

។ នៅឆ្នាំ 2019 ខ្ញុំបានភ្ជាប់បណ្តាញមេបណ្តាញ EOS របស់ DDOS ហើយបានបង្កកវារយៈពេលមួយខែដោយទាញយកកំហុសនៅក្នុងគំរូនៃធនធានការយល់ស្របរបស់វា។ EOS ជាប់ចំណាត់ថ្នាក់កំពូល 7 នៅពេលនោះ។ ( ) ខ្ញុំឈ្មោះ Dexaran ។ ខ្ញុំជាអ្នកលួចចូល ខ្ញុំបានរចនា និងប្រតិបត្តិការវាយប្រហារកម្រិតការយល់ស្របដ៏ធំបំផុតមួយនៅក្នុងឧស្សាហកម្មនេះ របាយការណ៍ EOSGO របាយការណ៍សហគមន៍ ។ ( ) ខ្ញុំជាស្ថាបនិកមួយនៃក្រុមអភិវឌ្ឍន៍ស្នូល Ethereum Classic អត្ថបទរបស់ Cointelegraph ខ្ញុំបានរចនា ដែលជាសំណុំនៃច្បាប់ដែល ដែលជាការគំរាមកំហែងនៃឧស្សាហកម្មសម្រាប់ខ្សែសង្វាក់ POW ។ វិសោធនកម្មទៅ Nakamoto consensus ដោះស្រាយការវាយប្រហារ 51% កំណត់សម្គាល់របស់អ្នកនិពន្ធ៖ រឿងនេះតំណាងឱ្យទស្សនៈរបស់អ្នកនិពន្ធរឿង។ អ្នកនិពន្ធមិនមានទំនាក់ទំនងជាមួយបុគ្គលិក HackerNoon ហើយសរសេររឿងនេះដោយខ្លួនឯងទេ។ ក្រុមវិចារណកថារបស់ HackerNoon បានត្រឹមតែផ្ទៀងផ្ទាត់រឿងសម្រាប់ភាពត្រឹមត្រូវតាមវេយ្យាករណ៍ប៉ុណ្ណោះ និងមិនថ្កោលទោស/ថ្កោលទោសការអះអាងណាមួយដែលមាននៅទីនេះទេ។ #DYOR គ្រោះថ្នាក់ អ្នកប្រើប្រាស់ម្នាក់បានបាត់បង់ 26,000,000 ដុល្លារនៃសញ្ញាសម្ងាត់ ezETH ដោយបញ្ជូនពួកគេទៅកិច្ចសន្យាឆ្លាតវៃ។ មានអត្ថបទជាច្រើននិងបណ្តាញធ្វីតធឺដែលអះអាងថានេះជាកំហុសអ្នកប្រើឧទាហរណ៍នេះដោយ ។ CoinTelegraph ។ ការផ្ទេរទៅអាសយដ្ឋានដែលគ្រប់គ្រងដោយខាងក្រៅ និងការផ្ទេរទៅកិច្ចសន្យាឆ្លាតវៃដំណើរការខុសគ្នា។ នេះមិនត្រឹមត្រូវ។ កំហុសរបស់អ្នកប្រើស្រដៀងគ្នានឹងមិនបណ្តាលឱ្យបាត់បង់និមិត្តសញ្ញា Eth, NFT ឬ ERC-223 ទេ ប្រសិនបើអ្នកប្រើនឹងផ្ញើសញ្ញាសម្ងាត់ទៅអាសយដ្ឋានខុស (ដែលមិនមែនជាកិច្ចសន្យាឆ្លាតវៃ) ឬអាសយដ្ឋានដែលមិនមែនជាកម្មសិទ្ធិរបស់នរណាម្នាក់ — នោះជាកំហុសរបស់អ្នកប្រើប្រាស់។ ទោះយ៉ាងណាក៏ដោយ ក្នុងករណីនេះ អ្នកប្រើប្រាស់បានដាក់ថូខឹនទៅកិច្ចសន្យាឆ្លាតវៃ។ Smart-contracts ត្រូវបានគេសន្មត់ថាដើម្បីការពារកំហុសនេះ ហើយពួកគេប្រាកដជាអាចធ្វើវាបាន - ឧទាហរណ៍ប្រសិនបើអ្នកប្រើនឹងដាក់ប្រាក់ Ether (ឬរូបិយប័ណ្ណដើមផ្សេងទៀត) NFTs (ERC-721) ឬ tokens ទៅ smart-contract ដែល មិនត្រូវបានរចនាឡើងដើម្បីទទួលពួកវា — បន្ទាប់មកសញ្ញាសម្ងាត់នឹងមិនត្រូវបានបាត់បង់។ វានឹងមានកំហុសក្នុងប្រតិបត្តិការ ហើយការផ្ទេរសញ្ញាសម្ងាត់នឹងមិនកើតឡើងទេ។ ERC-223 ការដោះស្រាយកំហុសគឺជាគោលការណ៍ជាមូលដ្ឋានបំផុតមួយនៃសុវត្ថិភាពកម្មវិធី។ ការរចនាកម្មវិធីក្នុងរបៀបដែលវានឹងមិនអាចដោះស្រាយកំហុសការហៅបានត្រឹមត្រូវគឺដូចគ្នានឹងការបាត់តែអ្នកកែប្រែ សម្រាប់មុខងារអភិបាលកិច្ច — ដែលនឹងជាបញ្ហាសុវត្ថិភាព។ onlyOwner នេះគឺជាបញ្ហានៃស្តង់ដារ ERC-20 - វាត្រូវបានរចនាឡើងតាមរបៀបដែលធ្វើឱ្យការដោះស្រាយកំហុសមិនអាចទៅរួច។ ហើយនេះគឺជាបញ្ហាសុវត្ថិភាព។ ។ នៅឆ្នាំ 2023 ។ ស្តង់ដារ ERC-20 មិនមានសុវត្ថិភាព អ្នកបង្កើតស្តង់ដារ ERC-20 ខ្លួនឯងបានបញ្ជាក់ថានេះគឺជាបញ្ហាសុវត្ថិភាពនៃស្តង់ដារ ខ្ញុំបានរាយការណ៍វានៅឆ្នាំ 2017 ។ ដូចគ្នានេះផងដែរខ្ញុំបានរចនាស្តង់ដារ ERC-223 ដើម្បីដោះស្រាយបញ្ហាពិតប្រាកដនេះក្នុងឆ្នាំ 2017 នេះគឺជាខ្សែស្រឡាយ ដែលវាត្រូវបានគូសបញ្ជាក់ថាស្តង់ដារនេះការពារការបាត់បង់ប្រាក់។ នៅ ទីនេះ EIP-223 ដើម វាងាយស្រួលពេកសម្រាប់ក្រុមហ៊ុនសន្តិសុខ និងអ្នកអភិវឌ្ឍន៍ក្នុងការបន្ទោសអ្នកប្រើប្រាស់ថាមានកំហុស។ ទោះជាយ៉ាងណាក៏ដោយ វាជាកំហុសរបស់អ្នកអភិវឌ្ឍន៍ដែលពួកគេបានបង្កើតកម្មវិធីរបស់ពួកគេដោយប្រើស្តង់ដារមិនសុវត្ថិភាព ដែលបរាជ័យក្នុងការដោះស្រាយកំហុសរបស់អ្នកប្រើប្រាស់ ដែលបណ្តាលឱ្យមានការខូចខាតយ៉ាងធ្ងន់ធ្ងរបែបនេះ។ ប្រវត្តិសាស្ត្រ ខ្ញុំបានគូសបញ្ជាក់ថា វាអាចបង្កការខូចខាតផ្នែកហិរញ្ញវត្ថុដល់អ្នកប្រើប្រាស់ ខណៈពេលដែលរាយការណ៍រឿងនេះទៅមូលនិធិ Ethereum។ ពួកគេមិនបានធ្វើអ្វីសោះ។ រយៈពេល 7 ឆ្នាំ។ មានការខាតបង់ចំនួន 16,000 ដុល្លារដោយសារតែបញ្ហានេះក្នុងឆ្នាំ 2017 ។ ក្នុងឆ្នាំ 2018 មានការខាតបង់ចំនួន 2,000,000 ដុល្លារ 60,000,000 ដុល្លារក្នុងឆ្នាំ 2023 នៅថ្ងៃទី 1 ខែវិច្ឆិកា ឆ្នាំ 2024 មាន $90,000,000 (មិនរាប់បញ្ចូល 25M ដែលបានបាត់បង់នៅក្នុងកិច្ចសន្យា ezETH) ឥឡូវនេះមាន 115,000,000 ដុល្លារ ក្រុមរបស់ខ្ញុំបានបង្កើតស្គ្រីបដែលគណនាចំនួនលេខសម្ងាត់ដែលបាត់៖ https://dexaran.github.io/erc20-losses នៅឆ្នាំ 2017 អ្នកប្រើប្រាស់ផ្សេងទៀតបានបាត់បង់ 130K ។ នៅឆ្នាំ 2020 អ្នកប្រើប្រាស់ម្នាក់បានបាត់បង់ការសង្គ្រោះជីវិតរបស់គាត់។ នៅឆ្នាំ 2023 អ្នកប្រើប្រាស់បានបាត់បង់ $240K ក្នុងប្រតិបត្តិការមួយ។ បន្ទាប់មកពួក Hacker Poloniex បានបាត់បង់ប្រាក់ចំនួន 2.5 លានដុល្លារ។ ខ្ញុំបានស្នើសុំឱ្យបញ្ឈប់ការលើកកម្ពស់ស្តង់ដារ ERC-20 ដោយសារតែបញ្ហាសុវត្ថិភាពនេះក្នុងឆ្នាំ 2017 មិនមានការឆ្លើយតប ។ https://github.com/ethereum/ethereum-org/issues/755 ខ្ញុំបានបង្កើនបញ្ហានេះទៅ EthereumCatHerders ដែលជាបុរសទាំងនោះដែលគ្រប់គ្រង EIPs នៅក្នុង Ethereum ។ នៅឆ្នាំ 2023 ពួកគេ "យើងមិនមានអ្វីដែលត្រូវធ្វើជាមួយការបង្ហាញសុវត្ថិភាពទេ យើងមិនមានដំណើរការសម្រាប់រឿងនោះទេ"។ បានឆ្លើយថា ការបញ្ជាក់៖ EIPs និង ERCs គឺជាសំណើដែលនរណាម្នាក់អាចដាក់ជូន Ethereum។ ពួកគេអាចក្លាយជាស្តង់ដារ ឬការកែប្រែដែល devs អនុវត្តចំពោះរបៀបដែល Ethereum ដំណើរការ។ ពួកវាជាឯកសារអត្ថបទនៅក្នុង github repo របស់ពួកគេ។ បរិបទ៖ ពួកគេមិនមានដំណើរការដើម្បីដោះស្រាយជាមួយនឹងការបង្ហាញសុវត្ថិភាពនៅក្នុង EIPs 10 ឆ្នាំបន្ទាប់ពីការចាប់ផ្តើមគម្រោង Ethereum ។ ខ្ញុំកំពុងស្នើវិធីសាស្រ្តដើម្បីកែប្រែរបៀបដែល EIPs ដំណើរការដើម្បីអនុញ្ញាតឱ្យមានការបង្ហាញសុវត្ថិភាព៖ https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265 ខ្ញុំបានស្នើឱ្យបន្ថែមការព្រមាននៅលើ ERC-20 និងកត់ត្រាបញ្ហានៅក្នុង EIPs ។ នេះគឺជាការហៅទូរសព្ទរបស់ពួកគេ ដែលពួកគេបានសម្រេចចិត្តថាខ្ញុំត្រូវតែទៅ និងបង្កើត EIP ផ្តល់ព័ត៌មានមួយផ្សេងទៀតដែលនឹងបង្ហាញភាពងាយរងគ្រោះនៅក្នុង EIP-20៖ https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317 ខ្ញុំបានធ្វើវា។ ពួកគេ ការបង្ហាញរបស់ខ្ញុំ EIP បន្ទាប់ពីនោះ។ បានច្រានចោល ខ្ញុំបានស្នើឡើងនូវសំណើរដើម្បីស្តារឡើងវិញនូវគំនិតដំបូងរបស់ខ្ញុំដែលខ្ញុំបានពិពណ៌នានៅលើវេទិកា EthereumMagicians ដែលនឹងអនុញ្ញាតឱ្យមានការបង្ហាញសុវត្ថិភាពនៅក្នុងផ្នែក "ការពិចារណាសុវត្ថិភាព" នៃ EIPs នៅឆ្នាំ 2024 ម្តងទៀត។ នេះជាការពិភាក្សារបស់ខ្ញុំជាមួយអ្នកកែសម្រួល EIP៖ https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s ជាលទ្ធផលអ្នកកែសម្រួល EIP បានប្រាប់ខ្ញុំថាពួកគេនឹងបោះឆ្នោតលើវា៖ https://github.com/ethcatherders/EIPIP/issues/349 សំណើរបស់ខ្ញុំត្រូវបានបោះឆ្នោតចេញ។ នៅតែមិនមានដំណើរការដើម្បីដោះស្រាយជាមួយនឹងការបង្ហាញសុវត្ថិភាពនៅក្នុង EIPs ទេ។ បញ្ហានៃ ERC-20 មិនត្រូវបានជួសជុលទេ។ វាមិនត្រូវបានរាយការណ៍ ឬចងក្រងជាឯកសារជាបញ្ហាទេ ដូច្នេះអ្នកអនុវត្តបន្តផលិតវាម្តងហើយម្តងទៀត។ សវនករអយុត្តិធម៌ ខ្ញុំផ្ទាល់បានរាយការណ៍បញ្ហានេះទៅ OpenZeppelin ដោយស្នើសុំការជួសជុល 3 ដង។ នៅឆ្នាំ 2018 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729 នៅឆ្នាំ 2023 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451 បន្ទាប់ពីពួកគេបានបដិសេធពីរលើកមុន ខ្ញុំបានសម្រេចចិត្តរាយការណ៍វាតាមរបៀបដែលបង្ហាញពីភាពធ្ងន់ធ្ងរនៃបញ្ហា ដូច្នេះខ្ញុំបានបញ្ជូនវាទៅ bug bounty របស់ពួកគេ ព្រោះវាសមនឹងលក្ខណៈវិនិច្ឆ័យ "ភាពងាយរងគ្រោះសុវត្ថិភាពសំខាន់" យោងទៅតាមច្បាប់របស់ពួកគេផ្ទាល់ https:/ /github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022 OpenZeppelin បានច្រានចោលវាជាមួយនឹង "ការបង្ហាញជាសាធារណៈអំពីភាពងាយរងគ្រោះដែលមិនបានជួសជុល" (ដែលបញ្ជាក់ថានេះគឺជាបញ្ហាសុវត្ថិភាពយ៉ាងហោចណាស់)។ ប៉ុន្មានថ្ងៃមុននៅ Devcon7 សំណួរមួយត្រូវបានសួរទៅកាន់បុរសដដែលនោះពី OpenZeppelin ដែលបានបិទបញ្ហានៅលើ github របស់ពួកគេទាក់ទងនឹងបញ្ហានោះ៖ https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406 6 ឆ្នាំបន្ទាប់ពីវាត្រូវបានគេរាយការណ៍ហើយបន្ទាប់ពីវាបានបណ្តាលឱ្យបាត់បង់ $ 115,000,000 ដល់អ្នកប្រើប្រាស់របស់ពួកគេ។ ការឆ្លើយតបរបស់ពួកគេមិនពិតទេ។ ជំនួសឱ្យបញ្ហាបើកចំហ ពួកគេបានបិទបញ្ហាចំនួន 3 ដែលខ្ញុំបានបើក ហើយបដិសេធរាល់អនុសាសន៍ដែលខ្ញុំបានធ្វើ។ សេចក្តីសន្និដ្ឋាន មូលនិធិ Ethereum កំពុងត្រួតពិនិត្យរាល់ការប៉ុនប៉ងដើម្បីរំលេចបញ្ហា ដែលបណ្តាលឱ្យអ្នកប្រើប្រាស់ប្រព័ន្ធអេកូបាត់បង់ $115,000,000។ បញ្ហាមិនត្រូវបានប្រកាសទេ ការបង្ហាញមិនត្រូវបានដោះស្រាយត្រឹមត្រូវទេ អ្នកអនុវត្តបន្តផលិតវាឡើងវិញក្នុងកិច្ចសន្យាថ្មី។ ខ្ញុំគិតថា គេចាត់ទុកថា វានឹងខូចកេរ្តិ៍ឈ្មោះគេពេកក្នុងការលាតត្រដាង។ សវនករដូចជា OpenZeppelin ក៏មិនបង្ហាញអំពីបញ្ហានេះដែរ ប្រហែលជាដោយសារតែពួកគេមានទំនាស់ផលប្រយោជន៍ ដូចដែលពួកគេបានដាក់ស្លាក "Secure" រួចហើយនៅលើកិច្ចសន្យា ERC-20 រាប់រយដែលពួកគេបានធ្វើសវនកម្ម។ Devs កំពុងនិយាយថា "យើងកំពុងអនុវត្តស្តង់ដារដូចដែលវាគឺ" ។ ស្តង់ដារត្រូវបានគ្រប់គ្រងដោយដំណើរការ EIP ដំណើរការ EIP មិនត្រូវបានបង្កើតឡើងសម្រាប់ដោះស្រាយជាមួយនឹងការបង្ហាញសុវត្ថិភាពនោះទេ។ ដំណើរការ EIP ត្រូវតែផ្លាស់ប្តូរ។ បញ្ហា ERC-20 ត្រូវតែបង្ហាញ និងចងក្រងឯកសារឱ្យបានត្រឹមត្រូវ។ តាមឧត្ដមគតិស្តង់ដារថ្មីត្រូវតែត្រូវបានអនុវត្ត។ ការអនុវត្តសំណុំនៃ "bandaids" នៅលើ ERC-20 ដើម្បីកាត់បន្ថយការខូចខាតគឺប្រសើរជាងមិនធ្វើអ្វីទាំងអស់ ប៉ុន្តែវាមិនអាចដោះស្រាយបញ្ហាបានទេ។ មនុស្សគ្រប់គ្នាដែលនិយាយថា "បញ្ហាអាចត្រូវបានដោះស្រាយនៅលើកម្រិតកាបូប" ខ្វះជំនាញសុវត្ថិភាព។ មានគោលការណ៍ នៅក្នុងសុវត្ថិភាពកម្មវិធី ដែលមានន័យថា អ្នកមិនអាចបង្កើតកម្មវិធីដែលមិនមានសុវត្ថិភាព ប្រាប់អ្នកគ្រប់គ្នាពីរបៀបប្រើវា ដើម្បីកុំឱ្យប៉ះពាល់ដល់អ្នកប្រើប្រាស់របស់អ្នក ហើយធ្វើពុតថាវានឹងមិនបង្កការខូចខាត។ មិននៅក្នុងឧស្សាហកម្មហិរញ្ញវត្ថុទេ។ វិធីសាស្រ្តនោះអាចដំណើរការក្នុងការរចនាគេហទំព័រ ជាឧទាហរណ៍ ដែលតម្លៃនៃកំហុសគឺនរណាម្នាក់មិនអាចផ្ទុកពុម្ពអក្សរត្រឹមត្រូវសម្រាប់គេហទំព័ររបស់ពួកគេ។ ក្នុងឧស្សាហកម្មហិរញ្ញវត្ថុ នេះជាលទ្ធផលខាតបង់រាប់លានដុល្លារ។ សុវត្ថិភាពដោយការរចនា វាមិនអាចទៅរួចទេក្នុងការធានាថាអ្នកអភិវឌ្ឍន៍កាបូបទាំងអស់នាពេលអនាគតទាំងមូលនៃអរិយធម៌របស់មនុស្សនឹងតែងតែអនុវត្តការកែតម្រូវចាំបាច់ទាំងអស់។