Balancer V2 Exploit อธิบาย: ภายในข้อผิดพลาดรอบสัญญาอัจฉริยะที่เสียค่าใช้จ่าย $ 120M

Technical Background of Balancer V2 Composable Stable Pools พื้นหลังทางเทคนิคของ Balancer V2 Composable Stable Pool : Pool Structure and How It Works สระว่ายน้ําที่มั่นคงแบบคอมโพสิตถูกสร้างขึ้นบนพื้นฐานของสถิติที่ได้รับแรงบันดาลใจจากรูปแบบ StableSwap ของ Curve What is a Composable Stable Pool? ปลั๊กเหล่านี้ได้รับการออกแบบมาเพื่อให้สินทรัพย์ที่มีมูลค่าเกือบเหมือนกันเช่น USDC และ DAI หรือ stETH และ ETH สามารถซื้อขายได้โดยมีการเลื่อนต่ําสุด **What makes them “composable”? \ The pool’s LP token (BPT) is a standard ERC-20 token that can be reused across the ecosystem, for example, in other pools or as collateral. This allows liquidity to be seamlessly composed throughout the system. **How it works \ A Composable Stable Pool can hold multiple tokens, and its invariant DDD is calculated using the following polynomial equation: ใน Balancer pool (สร้างแรงบันดาลใจจาก Curve) swaps จะถูกคํานวณโดยการเก็บรักษา (D) อย่างต่อเนื่องที่สุดเท่าที่จะเป็นไปได้ เมื่อการแลกเปลี่ยนเกิดขึ้นสมดุลของโทเค็นจะย้ายไปสู่สถานะใหม่ที่เก็บรักษาตัวแปรนี้ สารสม่ําเสมอข้างต้นคือ คุณตัดสินใจที่จะได้รับ ของ token ที่คุณแก้ปัญหาสําหรับเนื่องจาก (D) เก็บไว้ stable invariant quadratic new balance (x) สัญญาณ (x): สมดุลใหม่ (หลังการแลกเปลี่ยน) ของ token ที่คุณทําการแลกเปลี่ยน (S): จํานวนของสมดุลของ tokens อื่น ๆ (ยกเว้น (x) ) (P): ผลของสมดุลของโทเค็นอื่น ๆ (ยกเว้น (x) ) (D): สระว่ายน้ําไม่เปลี่ยนแปลง (มีเป้าหมายที่จะยังคงคงอยู่ทั่วสลับ) (A): พารามิเตอร์การขยายตัว (แบนเส้นโค้ง →เลื่อนต่ําสําหรับสินทรัพย์ที่มีมูลค่าเท่ากัน) (n): จํานวน tokens ในสระว่ายน้ํา วิสัยทัศน์: เราบีบอัด “ tokens อื่น ๆ ทั้งหมด” ในสองกลุ่ม (S) และ (P) การบังคับให้ “(D) stays constant” ให้ผล . quadratic in (x) ทําไมสี่เหลี่ยม หลังจากแยกสมดุลใหม่ของโทเค็นที่ไม่รู้จักและพับส่วนที่เหลือเป็น (S) และ (P) เงื่อนไขที่ไม่เปลี่ยนแปลงจะลดลงเป็น polynomial องศาที่สองใน (x) ดังนั้นคุณจะแก้สี่เหลี่ยม แก้ไขมัน เลือกรากซึ่งเป็น และ (ภายในช่วงสมดุลที่สามารถทําได้) รากที่สองมักจะเป็นเชิงลบหรือไม่มีความหมาย Which root? positive economically valid ตัวอย่างง่ายๆ Setup (2 tokens, large A → very low slippage) อัตราแลกเปลี่ยนการเริ่มต้นภายใน: token0 = 1,000,000; token1 = 1,000,000 จํานวน tokens: n = 2 การขยายตัว: A = 1000 ด้วยขนาดใหญ่ A, D ≈ 2,000,000 Action คุณเพิ่ม 10,000 หน่วยของ token0 (EXACT_IN) Quadratic to solve x^2 + (S - D/(A*n^n) - D)*x - D^(n+1)/(A*n^(2n)*P) = 0 ที่: , และ เป็นสมดุลหลังการแลกเปลี่ยนของ token1 S = 1,010,000 P = 1,010,000 x Solution x ≈ 990,999.546 Amount out amountOut = 1,000,000 - 990,999.546 ≈ 9,000.454 Interpretation คุณใส่ 10,000 ของ token0 และได้รับ ~9,000.45 ของ token1 → เลื่อนต่ํากับ A ใหญ่ คณิตศาสตร์ทั้งหมดใช้หน่วยภายใน 18 decimal; การประยุกต์ใช้รอบลงเพื่อความปลอดภัย ที่ใช้ (ระดับสูง) EXACT_IN: คุณเพิ่ม token input; แก้ไขสําหรับสมดุลใหม่ของ counter-token (x); ความแตกต่างจากสมดุลเก่าคือจํานวนออก EXACT_OUT: คุณเป้าหมายจํานวนเงินที่ได้รับเฉพาะเจาะจง; แก้ไขสําหรับที่จําเป็น (x) (และดังนั้นการป้อนข้อมูลที่จําเป็น) เส้นทางนี้มีความไวทางตัวเลขมากขึ้น (การค้นหาราก + รอบ) บันทึกการปฏิบัติ ความสมดุลทั้งหมดจะถูกจัดการภายในที่ 18 decimal (สแควร์) การคํานวณมักจะกลมลงเพื่อให้ปลอดภัย หนึ่งที่ใหญ่กว่า (A) ทําให้เส้นโค้งดูเหมือนกับจํานวนคงที่มากขึ้น (การลื่นตัวเล็ก ๆ สําหรับคู่ที่มั่นคง) และหนึ่งที่เล็กกว่า (A) จะใกล้เคียงกับพฤติกรรมของผลิตภัณฑ์คงที่ TL;DR: สารเคมีนี้เป็นสี่เหลี่ยมสี่เหลี่ยมซึ่งภายใต้ตัวแปรคงที่ (D) ให้คุณสมดุล token ใหม่ (x) หลังจากการแลกเปลี่ยน ค่าสัมประสิทธิ์เข้ารหัส "ส่วนที่เหลือของสระว่ายน้ํา" ผ่าน (S) และ (P) ในขณะที่ (A) และ (n) กําหนดรูปร่าง / ความเรียบของเส้นโค้งที่มั่นคง ความสม่ําเสมอนี้คือ ซึ่งภายใต้ตัวแปรคงที่ (D) ให้คุณ หลังจากแลกเปลี่ยน ค่าสัมประสิทธิ์เข้ารหัส "ส่วนที่เหลือของสระว่ายน้ํา" ผ่าน (S) และ (P) ในขณะที่ (A) และ (n) กําหนดรูปร่าง / พื้นของเส้นโค้งที่มั่นคง TL;DR: workhorse quadratic new token balance (x) The pool enforces a ระหว่างการสมดุลของโทเค็นที่จับโดย . balance relationship invariant D เมื่อคุณแลกเปลี่ยนสมดุลหนึ่งจะเพิ่มขึ้นอีกหนึ่งจะลดลงและสระว่ายน้ําจะพบ นี่คือวิธีที่ราคาเกิดขึ้น new balance that keeps D as constant as possible สระว่ายน้ําใช้ปัจจัยการปรับขนาดเพื่อปกติ tokens ไปยัง 18 decimals การดําเนินงาน Upscale กําหนดสมดุลเพื่อความแม่นยําภายในและใช้การกลมลง Swap Types EXACT_IN (GIVEN_IN): จํานวนการป้อนข้อมูลคงที่คํานวณการส่งออก EXACT_OUT (GIVEN_OUT): จํานวนการส่งออกคงที่คํานวณ input. Exploit มุ่งเน้นที่นี่. Vault และ BatchSwapBalancer Vault จัดการการดําเนินงานทั้งหมด BatchSwap รวมการแลกเปลี่ยนหลายครั้งในการทําธุรกรรมเดียวและใช้ "การชําระเงินล่าช้า" เช่น flashloans BPTs ทําหน้าที่เหมือน tokens ธรรมดาโดยการหลีกเลี่ยงขอบเขตการจัดหาสปูลมินเพื่อลดความคล่องตัวต่ํามาก 1. การวิเคราะห์การใช้งาน 1.1 การโจมตี On November 3, 2025, at around 7:40 AM UTC, specific Balancer v2 stable pools were targeted with a sophisticated attack that resulted in a cumulative loss of $120+ million across Balancer and its forks. The attack leveraged several circumstances: ส่วนใหญ่ของสระว่ายน้ําเป้าหมายเป็นตัวอย่างของสัญญา ComposableStablePool สระว่ายน้ําพิเศษที่ออกแบบมาสําหรับสินทรัพย์ที่คาดว่าจะแลกเปลี่ยนอย่างสม่ําเสมอในเกือบเท่ากันหรือในอัตราแลกเปลี่ยนที่รู้จัก ฟังก์ชั่น batchSwap ของสัญญา Balancer Vault ช่วยให้การแลกเปลี่ยนชั่วคราวเกิดขึ้นก่อนที่จะจําเป็นต้องชําระเงิน delta ที่เหลือ การโจมตีมีผลกําไรในสถานการณ์ที่มีเสถียรภาพต่ํา ผู้โจมตีต้องเตรียมการแลกเปลี่ยนขนาดใหญ่เพื่อให้สมดุลของสปูลสามารถนําไปสู่ความเสถียรภาพต่ําของ token หนึ่งหรืออีกวิธีที่ใช้มากที่สุดในการทําเช่นนี้คือการแลกเปลี่ยน tokens LP สําหรับ tokens pool ทําให้สปูลอยู่ในสภาพเสถียรภาพต่ํา ทั้งหมดข้างต้นเป็นเพียงสิ่งจําเป็น แต่ไม่ได้เป็นเหตุการณ์ที่สรุปด้วยเหตุการณ์ที่จําเป็นเพียงอย่างเดียวเพื่อให้เกิดเหตุการณ์นี้เป็นสาเหตุพื้นฐานของปัญหาพฤติกรรมการกลมกลมในฟังก์ชั่น _upscale ตัวแทนการโจมตีถูกนํามาใช้ครั้งแรกในวันที่ 16 กรกฎาคม 2021 เมื่อ MetaStablePool ผ่านการโจมตี ฟังก์ชั่นที่ commit 059284e. การเปลี่ยนแปลงเดียวกันถูกนําไปใช้ในวันที่ 1 กันยายน 2021 สําหรับสระว่ายน้ําเชิงเส้นที่ commit 4e9e70a และในวันที่ 20 กันยายน 2021 ในสระว่ายน้ํา f450760 สําหรับ StablePhantomPool, หลังจากนั้นเปลี่ยนชื่อเป็น ComposableStablePool. การตรวจสอบก่อนหน้านี้ของ OpenZeppelin ไม่ครอบคลุมสระว่ายน้ําเหล่านี้ที่มีเวกเตอร์การโจมตีนี้ _scalingFactors ในคําอธิบายปัญหาด้านล่างเราอธิบายว่าทําไมการแนะนํา override นี้เป็นหลักของการโจมตี 1.2 ปัญหา ฟังก์ชั่น batchSwap ของสัญญา Vault เป็นจุดเข้าสู่การโจมตีนี้ ผู้โจมตีสร้างการเรียกร้องไปยังมันโดยมุ่งเน้นไปที่ตัวอย่างของ ComposableStablePool โลจิกที่เกี่ยวข้องในสัญญา Vault ที่นําไปสู่การโต้ตอบของ ComposableStablePool ถูกกําหนดโดยการไหลนี้: batchSwaps →เรียกร้องภายใน _swapWithPools → ซึ่งเรียกร้องภายในสําหรับแต่ละ swap ที่ _swapWithPool → _processGeneralPoolSwapRequest→ในที่สุดเรียกร้อง onSwap บน ComposableStablePool เมื่อ landed ใน ComposableStablePool การดําเนินงานจะดําเนินการต่อไปใน hook onSwap ที่สองสิ่งเกิดขึ้น: การเรียกใช้ฟังก์ชั่น _scalingFactors การส่งมอบไปยัง _swapGivenOut ตามที่กําหนดไว้ในธุรกรรมตัวอย่างที่ระบุไว้ข้างต้น โปรดทราบว่าผู้โจมตีอาจตัดสินใจที่จะใช้รูปแบบ _swapGivenIn แต่การป้อนข้อมูลที่ระบุไว้ในธุรกรรมโจมตีแสดงให้เห็นถึงการเลือก ฟังก์ชั่นนี้จะเรียกฟังก์ชั่น _upscale ลองดูสองฟังก์ชั่นเหล่านี้ _ScalingFactors function _scalingFactors() internal view virtual override returns(uint256[] memory) { uint256 totalTokens = _getTotalTokens(); uint256[] memory scalingFactors = new uint256[](totalTokens); for (uint256 i = 0; i < totalTokens; ++i) { scalingFactors[i] = _getScalingFactor(i).mulDown(_getTokenRate(i)); } return scalingFactors; } ฟังก์ชั่นนี้ทํา 2 สิ่ง: มันสแกนปริมาณใด ๆ ไปยังจํานวน decimals ที่คงที่ตามที่แนะนําโดยฟังก์ชั่น _getScalingFactor และสิ่งที่กลับ มันมีปัจจัยในอัตราแลกเปลี่ยน token โดยการทําซ้ําด้วยปัจจัยการขยายตัวและแบ่งด้วย 1e18 อัปสแกน function _upscale(uint256 amount, uint256 scalingFactor) pure returns (uint256) { /* Upscale rounding wouldn't necessarily always go in the same direction: in a swap for example the balance of token in should be rounded up, and that of token out rounded down. This is the only place where we round in the same direction for all amounts, as the impact of this rounding is expected to be minimal. */ return FixedPoint.mulDown(amount, scalingFactor); } นี้ทําเพียงแค่ multiplication ของจํานวนโดยปัจจัยการขยายตัวของมันแบ่งด้วย 1e18 ในตอนท้าย ปัญหาอยู่ในสองข้อเท็จจริง: ฟังก์ชั่นเหล่านี้มักจะกลมลง (mulDown) โดยไม่คํานึงถึงทิศทางของการแลกเปลี่ยน หากจํานวนเงินเป็นคําสั่งขนาดเล็กกว่าคําสั่ง scalingFactors การสูญเสียความแม่นยําจะกลายเป็นที่ไม่น่าเบื่อ ในธุรกรรมผู้โจมตีค่าทั่วไปของจํานวนเงินและปัจจัย scaling คือ: จํานวน: "17"scalingFactor: "1058132408689971699" ถ้าเราคํานวณ เราได้รับ แต่เนื่องจาก Solidity truncates decimals นี้จะกลายเป็น , resulting in a ใน the การทํางาน amount * scalingFactor / 1e18 17.98 17 0% net change _upscale ตอนนี้พิจารณาปริมาณของ ( token กับ 18 decimals) ผลลัพธ์คือ เป็นตัวแทน a ซึ่งสะท้อนถึงอัตราที่ถูกต้อง 17,000000000000000000 17.988250950000000000 5.8% increase เช่นเดียวกับสําหรับ token กับ (เช่นเดียวกับ stablecoins ส่วนใหญ่มี) ใช้จํานวนมากของ ใบเสนอราคา ซึ่งยังคงสอดคล้องกับเกือบเดียวกัน . 6 decimals 17,000000 17.988250 5.8% positive change Truncation ได้รับการเพิ่มขึ้นโดยการทํา ขนาดที่ใหญ่ที่สุดเท่าที่จะเป็นไปได้เพื่อให้ผลิตภัณฑ์สูญเสียความแม่นยําสูงสุดเมื่อแบ่งด้วย 1e18 amount*scalingFactor mod 1e18 ตัวอย่างเช่นในตารางด้านล่างจํานวน=17 และจํานวน=50 ทั้งสองผลิตการสูญเสียรอบแน่นอนประมาณ 0.90 อย่างไรก็ตามข้อผิดพลาดเป็นเปอร์เซ็นต์ของจํานวนแตกต่างกันอย่างมีนัยสําคัญและเปอร์เซ็นต์ของการเพิ่มสูญเสียแตกต่างกันยิ่งขึ้นเนื่องจากความสูญเสียแน่นอนเดียวกันมีขนาดใหญ่กว่า 17 เมื่อเทียบกับ 50 ตัวอย่าง ตาราง 1 ตัวอย่างของข้อผิดพลาดการกลมกลมพื้นเมื่อปรับขนาดด้วยปัจจัย 1.058132408689971699 amount upscale error %error %increase lost 17 17 0.98 5.76% 100% 50 52 0.90 1.80% 17% ... ... ... ... ... 17 17 0.98 5.76% 100% 50 52 0.90 1.80% 17% ... ... ... ... ... โซ ฟังก์ชั่นจะใช้ค่ารอบเหล่านี้ในภายหลังเพื่อคํานวณจํานวนเงินที่ผู้โจมตีต้องจ่ายกับสระว่ายน้ําหลังการแลกเปลี่ยน ค่านี้จะถูก deflated โดยอัตโนมัติทําให้การแลกเปลี่ยนถูกกว่า กลไกภายในของสระว่ายน้ํา มีความซับซ้อนและพวกเขายังพิสูจน์ว่าทําไมจึงสามารถบรรลุได้ในสระว่ายน้ําที่มีเสถียรภาพต่ําที่สามารถได้รับได้ตามความปรารถนา นี่เป็นเพราะการตรวจสอบแบบไม่เปลี่ยนแปลงที่มั่นใจถึงการเข้ากันได้ในระดับบางอย่าง ในสถานการณ์ที่มีเสถียรภาพสูงการเปลี่ยนแปลงขนาดใหญ่ในสมดุลจะล้มเหลวเนื่องจากการป้องกันแบบไม่เปลี่ยนแปลงเดียวกัน _swapGivenOut _swapGivenOut ในที่สุด, ด้วยจํานวนการทําซ้ําสูง, เดลต้าหลังจาก batchSwap จะพองขึ้นให้ผู้โจมตีมีส่วนใหญ่ของเงินในสระว่ายน้ํา นอกจากนี้ยังมีคําสังเกตที่เกี่ยวข้องที่จะทําเกี่ยวกับ _upscale ในบรรทัด docstrings: /* Upscale rounding wouldn't necessarily always go in the same direction: in a swap for example the balance of token in should be rounded up, and that of token out rounded down. This is the only place where we round in the same direction for all amounts, as the impact of this rounding is expected to be minimal. */ เวอร์ชันก่อนหน้านี้ของความคิดเห็นนี้มีคําเตือนเพิ่มเติม: /* …as the impact of this rounding is expected to be minimal (and there's no rounding error unless `_scalingFactor()` is overriden). */ นี่เป็นสิ่งสําคัญเพราะ , นําเสนอใน และในภายหลังเปลี่ยนชื่อเป็น การประยุกต์ใช้ที่ถูกต้อง override พูดคุยข้างต้น StablePhantomPool September 20, 2021 ComposableStablePool _scalingFactor ในรุ่นก่อนหน้านี้ของ การ ฟังก์ชั่นเพียงคํานวณความแตกต่างในโทเค็น decimals อย่างไรก็ตามในแอพพลิเคชันล่าสุดก็รวมถึง ทําเครื่องหมายการเปลี่ยนแปลงพื้นฐาน StablePool _scalingFactor exchange rate ตามที่ระบุไว้ใน ความคิดเห็นของฟังก์ชั่นรหัสที่พัฒนาขึ้นจากการใช้ (เช่น ) สอง การเปลี่ยนแปลงนี้ในขณะที่จําเป็นในเชิงปฏิบัติการจะนําเสนอศักยภาพ และพร้อมกับพวกเขาน่าใหม่ . _upscale unitary scaling factors 1e12 non-unitary exchange rates rounding errors attack vector ในขณะที่การเปิดใช้งานข้อผิดพลาดการกลมกลมเป็นสาเหตุหลัก การใช้มันต้องใช้กลไกโปรโตคอลเพิ่มเติมและขั้นตอนการโจมตีเฉพาะ Balancer's batchSwap ช่วยให้สมดุลภายในชั่วคราวซึ่งเป็น net-settled เท่านั้นในตอนท้ายของชุด ด้วยเหตุนี้ผู้โจมตีมีประสิทธิภาพ " borrowed" BPT ภายในชุดเพื่อจัดการกับสระว่ายน้ําโดยไม่ต้องหยุดการทําธุรกรรมที่ถือครอง BPT BPT (Balancer Pool Token) เป็น ERC-20 ซึ่งแสดงให้เห็นว่าส่วนแบ่งของสล็อต Balancer ในบางสล็อตการออกแบบรวมถึงการกําหนดเป้าหมาย ComposableStablePools BPT ยังสามารถปรากฏเป็นทรัพย์สินสล็อตและสามารถแลกเปลี่ยนได้ ขั้นตอนแรกกระตุ้นสมดุล token pool (เช่น WETH / osETH) ไปยังระดับต่ํามาก (เกือบ 100k) โดยการแลกเปลี่ยน BPT เป็น token1 และ BPT เป็น token2 ด้วยความสมดุลขนาดเล็กกลมจุดคงที่กลายเป็นที่โดดเด่น วัตถุประสงค์คือการเพิ่มสูงสุดส่วนแบ่งที่ถูกลบออกในคํานวณพื้นดินเช่นเพิ่มปริมาณ * scalingFactor mod 1e18 เพื่อให้ผลิตภัณฑ์สูญเสียความแม่นยํามากที่สุดเท่าที่จะเป็นไปได้เมื่อแบ่งด้วย 1e18 ในความสมดุลที่เพียงพอต่ําการเพิ่มเต็มรูปแบบที่ตั้งใจสามารถถูกลบออก นี่คือจุดที่ได้รับสูงสุดและสิ่งที่แฮ็กเกอร์กําลังมองหา Exploit ทํางานในการทําซ้ํา triplets ของ swaps: Prime: ย้ายสระว่ายน้ําไปยังสถานะที่ truncation จะเกิดขึ้นในการดําเนินการถัดไป ในภาพหน้าจอด้านล่างการแลกเปลี่ยนของ WETH ไปยัง osETH ใช้ประโยชน์: ดําเนินการแลกเปลี่ยนที่รับรู้การสูญเสียการกลมกลม ในภาพหน้าจอแลกเปลี่ยน 17 WETH สําหรับ osETH รีเซ็ต: รีเซ็ตสมดุลเพื่อให้สามารถเล่นซ้ํา triplet ในภาพหน้าจอคือการแลกเปลี่ยน osETH ไปยัง WETH ตามที่แสดงในแถบด้านล่างการแลกเปลี่ยนที่สําคัญมักจะใช้จํานวน=17 เมื่อเทียบกับสมดุลกล่อง 18 คุณสามารถเห็นจํานวน 17 ครั้งที่ซ้ํากันในแลกเปลี่ยนที่สองของแต่ละ triplet 2. การพัฒนาแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัย: บทเรียนสําหรับอุตสาหกรรม เหตุการณ์นี้ได้กระตุ้นการอภิปรายเกี่ยวกับประสิทธิภาพของการตรวจสอบความปลอดภัยของสัญญาอัจฉริยะซึ่งนักวิจารณ์บางคนสงสัยว่าพวกเขามีคุณค่าหรือไม่ แม้ว่าความรู้สึกนี้อาจเข้าใจได้ในช่วงเวลาของความผิดหวัง แต่ก็ไม่ยอมรับว่าทําไมการตรวจสอบความปลอดภัยได้กลายเป็นแนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรมและผลกระทบอย่างมากที่ปฏิบัติการการตรวจสอบความปลอดภัยมีต่อการลดความเสี่ยงและปกป้องผู้ใช้ในช่วงทศวรรษที่ผ่านมา บริษัท การรักษาความปลอดภัยร่วมกันป้องกันการล้มเหลวเป็นไปได้หลายร้อยรายทุกปี OpenZeppelin เท่านั้นได้ระบุความเสี่ยงที่สําคัญและมีความรุนแรงสูงกว่า 700 เท่านั้นก่อนที่พวกเขาเข้าถึงการผลิตในทุกการตรวจสอบของเรา ภัยพิบัติที่หลีกเลี่ยงเหล่านี้ไม่ได้เป็นหัวข้อ แต่พวกเขาแสดงให้เห็นถึงมูลค่าที่ได้รับการปกป้องเป็นพันล้านและผู้ใช้จํานวนมากที่ถูกบันทึกจากความสูญเสีย การตรวจสอบความปลอดภัยที่มีคุณภาพสูงยังช่วยให้ทีมพัฒนาปรับปรุงทัศนคติความปลอดภัยของพวกเขาตลอดวงจรชีวิตของการพัฒนาซึ่งส่งผลให้ลดความน่าจะเป็นของข้อผิดพลาดเพิ่มเติมที่นํามาใช้ในแอพพลิเคชัน blockchain บทเรียนที่แท้จริงไม่ได้คือการตรวจสอบไม่มีประสิทธิภาพ - มันคือการปฏิบัติการการตรวจสอบของอุตสาหกรรมยังไม่ได้ตระหนักถึงความเร็วในการพัฒนาโปรโตคอลที่ซับซ้อนที่ช่วยให้มั่นใจในมูลค่าที่สําคัญ เนื่องจากการตรวจสอบมักจะครอบคลุมเป็นการตรวจสอบแบบแยกต่างหากแทนการมีส่วนร่วมอย่างต่อเนื่องการเชื่อมโยงสามารถสูญเสียเมื่อฐานรหัสพัฒนา การเปลี่ยนแปลงนี้ต้องมีการเปลี่ยนแปลงร่วมกัน: ทีมโปรโตคอลลงทุนในการรักษาความปลอดภัยอย่างต่อเนื่องและผู้ตรวจสอบสร้างกรอบที่สนับสนุน 2.1 การสร้างความปลอดภัยอย่างต่อเนื่องเป็นมาตรฐานอุตสาหกรรม ผลลัพธ์ Balancer v2 แสดงให้เห็นว่าทําไมเราได้สนับสนุนการเปลี่ยนแปลงพื้นฐานในวิธีการที่อุตสาหกรรมเข้าถึงความปลอดภัย ตั้งแต่การเปิดตัวการปฏิบัติการการตรวจสอบสัญญาอัจฉริยะในปี 2016 เราได้เห็นว่าผลลัพธ์ด้านความปลอดภัยที่ประสบความสําเร็จมากที่สุดมาจากความร่วมมือด้านความปลอดภัยอย่างต่อเนื่องซึ่งครอบคลุมฐานรหัสโปรโตคอลทั้งหมดและการเปลี่ยนแปลงทั้งหมดของพวกเขาตามเวลาแทนที่จะมีการตรวจสอบรหัสแบบ ad hoc ของการอัพเกรดที่สําคัญซึ่งมักจะ จํากัด ในช่วงเฉพาะการเปลี่ยนแปลงเหล่านี้ เมื่อนักวิจัยด้านความปลอดภัยทํางานกับโปรโตคอลอย่างต่อเนื่องพวกเขาพัฒนาความคุ้นเคยอย่างลึกซึ้งกับสถาปัตยกรรมของโปรโตคอลกระบวนการวิศวกรรมและเหตุผลที่ตัดสินใจการออกแบบที่เฉพาะเจาะจงได้รับการทํา ความเข้าใจที่ลึกซึ้งนี้ลดความเสี่ยงอย่างมีนัยสําคัญเมื่อเปรียบเทียบกับการตรวจสอบ ad hoc แม้ว่าฐานรหัส Balancer v2 ได้รับการตรวจสอบโดยสี่ บริษัท การตรวจสอบอิสระ แต่ละ บริษัท ฯ ได้มุ่งมั่นที่จะมุ่งเน้นไปที่ขอบเขตที่แตกต่างกันของโปรโตคอล การมีส่วนร่วมของผู้ตรวจสอบหลายคนช่วยลดความเป็นไปได้ของการขาดความเสี่ยง แต่การรักษาอย่างน้อยหนึ่งพันธมิตรด้านความปลอดภัยระยะยาวให้ความเข้าใจอย่างลึกซึ้งและต่อเนื่องเกี่ยวกับวิธีการพัฒนาฐานรหัสและวิธีการเปลี่ยนแปลงใหม่มีปฏิสัมพันธ์กับกลยุทธ์ที่มีอยู่ 2.2 การสร้างกรอบความปลอดภัยที่ดีขึ้น OpenZeppelin Contracts ได้กลายเป็นมาตรฐานในความเป็นจริงสําหรับการสร้างสัญญาอัจฉริยะที่ปลอดภัย ขณะนี้มีมูลค่ารวมกว่า 30 พันล้านดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ดอลลาร์ นอกเหนือจากความสัมพันธ์ระยะยาวกับลูกค้าของเราเรากําลังทํางานอย่างกระตือรือร้นเพื่อสร้างมาตรฐานเหล่านี้ทั้งในระดับอุตสาหกรรมและระดับการควบคุม ตัวอย่างเช่น OpenZeppelin มีส่วนร่วมในหน่วยงานจัดตั้งมาตรฐานอุตสาหกรรมเช่นคณะกรรมการมาตรฐานความปลอดภัย Blockchain, Enterprise Ethereum Alliance และองค์กรมาตรฐานนานาชาติ (ISO) เพื่อให้แน่ใจว่าการปฏิบัติที่ดีที่สุดด้านความปลอดภัยของทีมและชุมชนของเราได้ช่วยให้อุตสาหกรรมทั้งหมดสามารถเข้าถึงได้ นอกจากนี้เรายังมีส่วนร่วมกับหน่วยงานกํากับดูแลและผู้ตัดสินใจทั่วโลกเพื่อให้แน่ใจว่าแนวทางปฏิบัติที่ดีที่สุดในการรักษาความปลอดภัยของ blockchain จะได้รับการส่งเสริมในระบบกํากับดูแลที่เกี่ยวข้อง โดยเฉพาะอย่างยิ่ง OpenZeppelin มีส่วนร่วมกับแผนกสกุลเงินของสหรัฐอเมริกาคณะกรรมการสกุลเงินสกุลเงินและคณะกรรมการแลกเปลี่ยนสหราชอาณาจักรคณะกรรมการพฤติกรรมทางการเงินของสหราชอาณาจักรและ ACPR และ AMF ฝรั่งเศสเกี่ยวกับประโยชน์ของการดําเนินการตรวจสอบความปลอดภัยที่ครอบคลุมอย่างสม่ําเสมอ นอกจากนี้เรายังได้สํารวจศักยภาพในการสร้างองค์กรการควบคุมตนเองที่เฉพาะเจาะจงคล้ายกับผู้ตรวจสอบในสาขาอื่น ๆ ที่เราเชื่อว่าสามารถช่วยให้เป็นทางการมาตรฐานการตรวจสอบความปลอดภัยและวิธีการสําหรับเทคโนโลยี blockchain กําหนดความต้องการด้านคุณภาพและจริยธรรมสําหรับผู้ตรวจสอบและจัดการการรับ 2.3 การเสริมสร้างระบบนิเวศการรักษาความปลอดภัย Blockchain ร่วมกัน ทุกเหตุการณ์ด้านความปลอดภัยให้ข้อมูลที่มีค่าซึ่งช่วยเพิ่มการปรับปรุงในอุตสาหกรรมของเรา การใช้ Balancer v2 ช่วยให้มั่นใจได้ว่าในขณะที่โปรโตคอลมีค่ามากขึ้นและซับซ้อนขึ้นจึงเป็นสิ่งสําคัญสําหรับทีมโปรโตคอลที่จะลงทุนในการรักษาความปลอดภัยอย่างต่อเนื่องเช่นเดียวกับการตรวจสอบ บริษัท เพื่อสร้างกรอบเพื่อสนับสนุนการรักษาความปลอดภัยร่วมกันเราสามารถสร้างวิธีการรักษาความปลอดภัยที่นวัตกรรมใหม่และมีประสิทธิภาพเท่าเทียมกันกับเทคโนโลยีที่พวกเขาปกป้อง