คำเตือนความเสี่ยง: ระวังความเสี่ยงจากการระดมทุนที่ผิดกฎหมายในนาม 'สกุลเงินเสมือน' 'บล็อกเชน' — จากห้าหน่วยงานรวมถึงคณะกรรมการกำกับดูแลการธนาคารและการประกันภัย
ข่าวสาร
ค้นพบ
ค้นหา
เข้าสู่ระบบ
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt
BTC
ETH
HTX
SOL
BNB
ดูตลาด
การวิเคราะห์เชิงลึกของตรรกะการออกแบบของรางแบบไขว้จากมุมมองของผลิตภัณฑ์
先知实验室
特邀专栏作者
2022-02-23 14:00
บทความนี้มีประมาณ 5202 คำ การอ่านทั้งหมดใช้เวลาประมาณ 8 นาที
โซลูชันครอสเชนที่เปลี่ยนแปลงตลอดเวลาจะนำคุณไปสู่การวิเคราะห์ตรรกะการออกแบบของแทร็กคร

คำนำ:

คำนำ:

ปัญหาด้านความปลอดภัยข้ามสายโซ่ที่พบบ่อยเมื่อเร็วๆ นี้ ได้รับความสนใจอย่างกว้างขวางจากตลาด บทความนี้ หวังว่าจะเริ่มต้นจากมุมมองของการออกแบบผลิตภัณฑ์และบอกผู้อ่านว่าทำไมจึงมีปัญหาด้านความปลอดภัยของผลิตภัณฑ์มากมายในเส้นทางนี้ ควรประกาศว่าปัญหาที่ชี้ให้เห็นในบทความไม่ได้มีอยู่ในทุกโครงการ ปัญหาส่วนใหญ่ได้รับการออกแบบโดยใช้กลยุทธ์การเผชิญปัญหาที่เกี่ยวข้อง จุดประสงค์หลักคือหวังว่าผู้คนจำนวนมากขึ้นสามารถเข้าใจความซับซ้อนของเส้นทางนี้

ชื่อเรื่องรอง

01. โซลูชันข้ามโซ่ที่เปลี่ยนแปลงตลอดเวลา

รายงานการวิจัยก่อนหน้านี้ได้อธิบายถึงวิธีการแก้ปัญหาข้อมูลข้ามโซ่ประเภทต่างๆ ให้กับทุกคน จริงๆ แล้ว ไม่ว่าการนำเสนอขั้นสุดท้ายจะเป็นอย่างไรจากมุมมองของการออกแบบผลิตภัณฑ์ มีเพียง side chains เท่านั้น (ในความหมายกว้างๆ ของ side chains ในข้อความ) ของการยกเลิก นอกจากนี้ยังสามารถสรุปได้เป็นสามกลไก: ห่วงโซ่ข้าง การล็อกเวลาแฮช และการรับรองเอกสาร

(1) โซ่ด้านข้าง

ในบรรดาสามโครงร่าง โครงร่างไซด์เชนมีความปลอดภัยสูงสุด เช่น โรลอัพและโพลกาดอทพาราเชนแบบต่างๆ มีการแบ่งปันความปลอดภัยระหว่างโซ่หลักและโซ่ข้าง อย่างไรก็ตาม รูปแบบไซด์เชนโดยทั่วไปต้องการให้เชนเดิมและเชนเป้าหมายเป็นแบบไอโซมอร์ฟิก ดังนั้นจึงมีสถานการณ์ที่เกี่ยวข้องน้อยกว่ามาก นี่เป็นเหตุผลที่ Vitalik เห็นด้วยกับ multi-chains แต่ไม่ใช่ cross-chain เนื่องจากมีปัญหามากเกินไปเกี่ยวกับโซลูชั่นแบบ cross-chain ที่ไม่สามารถแบ่งปันความปลอดภัยได้

(2) ล็อคเวลาแฮช

โซลูชันนี้อ้างว่าเป็นโซลูชันข้ามเชนแบบเพียร์ทูเพียร์ที่มีการกระจายอำนาจมากที่สุด แต่ต้นทุนสูงและเวลารอสำหรับผู้ใช้นานเกินไป ส่งผลให้อัตราการนำไปใช้ในปัจจุบันไม่สูง และเมื่อเรายังต้องการบุคคลที่สามเพื่อทำหน้าที่เป็นโหนดกลางสำหรับการแลกเปลี่ยนสกุลเงิน เรายังต้องการชั้นฉันทามติระดับกลางเพื่อให้เป็นไปตามข้อกำหนดด้านความปลอดภัยและการกระจายอำนาจ

(3) กลไกการรับรองเอกสาร

ปัจจุบันนี่เป็นโซลูชันสะพานข้ามโซ่ข้ามชนิดที่ใช้บ่อยที่สุด ผลิตภัณฑ์ส่วนใหญ่ในตลาดโดยพื้นฐานแล้วมาจากแหล่งกำเนิดเดียวกัน และแทบไม่มีความแตกต่างจากมุมมองของการออกแบบผลิตภัณฑ์ ความแตกต่างหลักอาจมุ่งเน้นไปที่วิธีการและขั้นตอนการตรวจสอบข้อมูล อัลกอริทึมที่สอดคล้องกันของทนายความ อัลกอริทึมลายเซ็นของกระเป๋าเงินเอสโครว์ เป็นต้น ไม่มีความแตกต่างกันมากนักในด้านประสบการณ์การใช้งานและความปลอดภัย ดังนั้น จากมุมมองด้านความปลอดภัย ความเสี่ยงด้านความปลอดภัยที่พบจึงมีลักษณะทั่วไปหลายประการ

ชื่อเรื่องรอง

02. การไหลของตรรกะผลิตภัณฑ์ของกลไกการรับรองเอกสาร

ก่อนที่จะเข้าใจถึงความเสี่ยงต่างๆ ที่กลไกการรับรองต้องเผชิญ เราจำเป็นต้องเข้าใจตรรกะการออกแบบของโซลูชันประเภทนี้จากมุมมองของผลิตภัณฑ์

(1) บทนำสั้น ๆ

คำอธิบายภาพ

กระบวนการข้ามสายโซ่ที่เรียบง่ายที่สุด

(2) ความยากลำบากในการออกแบบ

จะมีปัญหามากมายในเรื่องนี้ ปัญหาที่ใหญ่ที่สุดคือการจัดการกระเป๋าเงินแบบหลายลายเซ็น เนื่องจาก ETH ที่ข้ามจาก Ethereum ไปยัง Fantom เป็นการฝากเงิน และหากผู้ใช้ A ต้องการข้ามกลับ ก็จะเกี่ยวข้องกับปัญหาการถอนเหรียญ

การกระจายอำนาจและความปลอดภัยของการฝากและถอนกลายเป็นปัญหาใหญ่ที่สุด

1. ใครจะเป็นคนจัดการเงิน? 2. ใครจะเป็นคนเริ่ม? 3. ใครจะเป็นผู้ตรวจสอบการทำธุรกรรม? 4. จะยืนยันได้อย่างไรว่าผู้ใช้โอนเงินเข้ามา? 5. จะยืนยันได้อย่างไรว่าเงินของผู้ใช้เป็นผู้ใช้ที่ต้องการถอนจริง 6. จะป้องกันการโจมตีซ้ำได้อย่างไร? 7. จะส่งธุรกรรมที่ล้มเหลวอีกครั้งได้อย่างไร? 8. ฉันควรทำอย่างไรหากผู้จัดการหลายลายเซ็นทำสิ่งชั่วร้าย? 9. ฉันควรทำอย่างไรหากมีการหยุดทำงาน?

ไม่กล้าคิด ยิ่งคิดก็ยิ่งซับซ้อน เทคโนโลยีของ cross-chain bridge ไม่เพียงแต่เกี่ยวข้องกับหลายลายเซ็นเท่านั้น แต่ยังเกี่ยวข้องกับการออกสินทรัพย์ การตรวจสอบข้ามเชน การตรวจสอบแบบอะซิงโครนัส และแม้แต่ความต้องการในการออกเลเยอร์ฉันทามติระดับกลางที่เป็นอิสระ (เชนใหม่)

ดังนั้นเพื่อให้ผู้ใช้เข้าใจได้ง่ายขึ้น ฉันจะแบ่งกระบวนการข้ามสายโซ่ทั้งหมดออกเป็นสองส่วน: การฝากและการถอนเงิน เพื่อช่วยให้คุณเข้าใจดีขึ้น

(3) การปรับแต่งเพิ่มเติมของกระบวนการ

1. เงินฝาก

ก่อนอื่น ผมขอประกาศว่ากระบวนการที่วาดในรูปด้านล่างเป็นเพียงแผนการออกแบบที่อนุมานจากตัวผมเองโดยไม่มีการโต้แย้งอย่างรอบคอบ จุดประสงค์คือ เพื่อสำรวจปัญหาด้านความปลอดภัยที่เป็นไปได้ในตรรกะการออกแบบ และไม่สามารถใช้เป็นแผนขั้นสุดท้ายได้ เรื่องไร้สาระทั้งหมด

ดังแสดงในรูป: ธุรกรรมการฝากจากเชนเดิมไปยังเชนเป้าหมายโดยหลักการแล้วจะประกอบด้วยขั้นตอนเหล่านี้:

(1) ผู้ใช้เติมเงินไปยังที่อยู่โฮสต์

(2) หลังจากที่ผู้ฟังตรวจสอบการทำธุรกรรม BP (โหนดฉันทามติยังเป็นผู้ดูแลระบบแบบหลายลายเซ็น) จะเริ่มการทำธุรกรรม

(3) สัญญาตรวจสอบความถูกต้องของลายเซ็น BP

(4) มีกลไกการยอมรับข้อบกพร่องของโหนดหรือไม่

(5) หากไม่มีการโทรกลับ หากมี ให้เติมเงินที่อยู่เชนเป้าหมายตามความสัมพันธ์ของที่อยู่แมป

(6) BP ยืนยันธุรกรรมการเติมเงิน

(7) โอนโทเค็นการแมปไปยังที่อยู่ของผู้ใช้บนเชนเป้าหมายหลังจากผ่าน Byzantium

ควรสังเกตว่ากระบวนการนี้มีจุดมุ่งหมายเพื่อหารือเกี่ยวกับ cross-chain ทั่วไปที่แตกต่างกัน ดังนั้นเมื่อเปรียบเทียบกับ anyswap และโซลูชันอื่น ๆ จะมีการเพิ่มขั้นตอนเพิ่มเติมเพื่อให้ผู้ใช้สามารถผูกความสัมพันธ์ที่อยู่บนชั้นฉันทามติระดับกลาง สาเหตุหลักมาจากวิธีต่างๆ ในการแนบข้อมูลกับธุรกรรมลูกโซ่ที่แตกต่างกัน เพื่อจัดการกับมันอย่างสม่ำเสมอ จะเป็นการดีกว่าหากให้ผู้ใช้ผูกความสัมพันธ์การแมปก่อน หากคุณกำลังจัดการกับธุรกรรมบนเชน EVM คุณไม่จำเป็นต้องทำขั้นตอนนี้ เพียงแนบที่อยู่ของเชนเป้าหมายเมื่อคุณเริ่มธุรกรรม

กลับไปที่หัวข้อ จะเห็นได้จากกระบวนการข้างต้นที่เริ่มต้นจากขั้นตอนที่สอง คุณจะพบกับปัญหาการตรวจสอบลอจิกและปัญหาการประมวลผลในสถานการณ์ต่างๆ

ตรรกะการตรวจสอบหลักประกอบด้วย:

(1) หลังจากฟังการทำธุรกรรม ตรวจสอบการแมปสินทรัพย์ที่เริ่มต้นและถ่ายโอนไปยังธุรกรรมลูกโซ่เป้าหมายของผู้ใช้ A

(2) การเริ่มต้นของธุรกรรมลูกโซ่เป้าหมายและการตรวจสอบผลลัพธ์ของการทำธุรกรรม แน่นอน นอกเหนือจากตรรกะการตรวจสอบที่อยู่ในกระบวนการของฉันแล้ว ควรรวมถึงการตรวจสอบปัญหาการเติมสกุลเงินปลอม และปัญหาการประมวลผลพิเศษที่ต้องทำเมื่อเรียกใช้ต่าง โทเค็น เพื่อให้สรุปถึงอันตรายด้านความปลอดภัยที่อาจเกิดขึ้นในอนาคตได้ดียิ่งขึ้น เรามาทำความเข้าใจขั้นตอนการถอนเหรียญกันต่อไป

2. ถอนเหรียญ

กระบวนการที่แสดงโดยการถอนเหรียญเป็นตรรกะของการแลกเปลี่ยนสินทรัพย์เชนเป้าหมายกลับไปยังสินทรัพย์เชนเดิม สิ่งสำคัญคือ โปรดทราบว่าโทเค็นจำนวนมากในปัจจุบันมีหลายเชนหลายเวอร์ชัน ซึ่งหมายความว่าโทเค็นจำนวนมากอยู่ในหลายเชน เป็นเจ้าของโทเค็นดั้งเดิม ดังนั้น โครงการบริดจ์บางโครงการจึงมักสร้างกลุ่มสินทรัพย์ ในกรณีของแหล่งเงินทุนที่เพียงพอ ผู้ใช้จะไม่รู้สึกถึงการมีอยู่ของสินทรัพย์ที่แมป เช่น anyDAI แต่จะแทนที่โดยตรงด้วยโทเค็นของเวอร์ชันห่วงโซ่เป้าหมาย แต่สิ่งนี้จะไม่ส่งผลกระทบต่อตรรกะโดยรวม ดังนั้น การวิเคราะห์จึงดำเนินต่อไป

ดังที่แสดงในรูป กระบวนการทำธุรกรรมจากเชนเป้าหมายไปยังเชนเดิมมีดังนี้: (1) ผู้ใช้เริ่มต้นธุรกรรม (โอนสินทรัพย์ที่แมปในจำนวนเท่ากันไปยังกระเป๋าเงินเอสโครว์บนเชนเป้าหมาย) (2 ) ตรวจสอบตัวตนของ BP BP เริ่มต้นคำขอถอนเหรียญ (3) ยืนยันอำนาจการถอนเหรียญและลายเซ็น (4) ดำเนินการตามคำขอถอนเหรียญในเชนเดิมหลังจากผ่าน Byzantium และโอนเงินจากกระเป๋าเงิน escrow ของเชนเดิมไปยังผู้ใช้ A (5) หากมีโหนดตรงกลาง ปัญหา เช่น ข้อผิดพลาดในการตรวจสอบหรือการหยุดทำงานจำเป็นต้องย้อนกลับและเริ่มต้นใหม่ จากกระบวนการ ข้างต้น จะเห็นได้ว่าตรรกะการตรวจสอบหลักที่เกี่ยวข้อง ในที่นี้คือ: (1) การตรวจสอบสิทธิ์ในการเริ่มต้นและลายเซ็น (2) กลไกการทนทานต่อความผิดพลาดหลังจากเกิดปัญหา

(4) ความเสี่ยงด้านความปลอดภัย

1. ปัญหาด้านความปลอดภัยในตรรกะการออกแบบ

หลังจากทำความเข้าใจอย่างรอบคอบมากขึ้นเกี่ยวกับการออกแบบสะพานข้ามโซ่ เราจะพบว่า มีความท้าทายมากมายในตรรกะการออกแบบของสะพานข้ามโซ่ โดยสรุปแล้ว มีปัญหาหลักสามประการ (กรณีที่ถูกขโมยที่เกี่ยวข้องระบุไว้ที่ ท้ายคำถาม)

(1) เงินฝาก

ก) มีช่องโหว่ในอำนาจของสัญญาการชาร์จเหรียญ ซึ่งนำไปสู่การโอนเงินที่เรียกเก็บโดยตรง นี่เป็นปัญหางี่เง่าที่โครงการสัญญาเกือบทั้งหมดจะต้องเจอ ข) ปัญหาการเติมสกุลเงินปลอม บางโครงการยังไม่ได้ตรวจสอบความถูกต้องของโทเค็นข้ามเชน ส่งผลให้มี TOKEN ปลอม -> realTOKEN (สลับแบบใดก็ได้) พูดตามตรง นี่มันค่อนข้างโง่ไปหน่อย d) ปัญหาการเติมสกุลเงินปลอม ETH และสินทรัพย์พื้นเมืองอื่น ๆ นั้นแตกต่างจากสัญญา ERC20 การโจมตีจำนวนมากเกิดจากการจัดการ ETH ที่ไม่เหมาะสม ส่งผลให้ ETH ปลอม -> realETH ซึ่งเป็นเหตุผลว่าทำไมสินทรัพย์แบบรวมเช่น WETH จึงเป็นที่นิยม (thorchain) c) แม้ว่า Token ที่แตกต่างกันจะเป็นมาตรฐาน ERC20 ทั้งหมด แต่วิธีการใช้งานเฉพาะนั้นแตกต่างกัน หรือมีตรรกะเพิ่มเติม (rebase, fallback ฯลฯ) ผู้พัฒนาไม่ได้ทำการวิจัยที่ดีเมื่อทำการปรับตัว เช่น ( WETH, PERI, OMT, WBNB, MATIC, AVAX) ฯลฯ จะเรียกใช้ฟังก์ชันสำรองที่กำหนดเองของผู้ส่งเพื่อดำเนินการเพิ่มเติมหลังจากการถ่ายโอนเสร็จสิ้น ซึ่งจะเพิ่มความซับซ้อนของการตัดสินสะพานข้ามสาย (anyswap 2022.1.18)

(2) การถ่ายโอนข้อความข้ามสายโซ่

หลังจากการเติมเหรียญของเชน a เสร็จสิ้น และก่อนที่ทรัพย์สินของเชน b จะมาถึงบัญชี สะพานข้ามเชนจะได้รับการจัดการเหมือนระบบบล็อกเชนอิสระ ซึ่งต้องใช้กลไกที่สอดคล้องกัน โดยทั่วไปจะใช้ dpos และสิ่งต่อไปนี้ทั้งหมด สันนิษฐานว่าจะใช้ปัญหา dpos ในการพิจารณา แต่ฉันสงสัยว่าโหนดทั้งหมดเป็นของฝั่งโครงการ และมีความเสี่ยงที่จะรวมศูนย์ตั้งแต่แรก a) เพื่อตรวจสอบข้อความการฝากเหรียญ ใครจะเป็นคนแรกที่เริ่มข้อเสนอการประมวลผลข้ามเครือข่ายแบบสุ่ม? หรือผลัดกัน? หรือตามลำดับของบล็อกที่ผลิตโดยชั้นฉันทามติระดับกลาง? b) ผู้รับรองหลายคนจะตรวจสอบความถูกต้องของเงินฝากได้อย่างไรหากแหล่งข้อมูลทั้งหมดมาจากผู้ให้บริการข้อมูลเช่น infura, infura เป็นจุดเสี่ยงเดียวสิ่งที่ปลอดภัยที่สุดคือการบำรุงรักษาโหนดของตนเองซึ่งมีค่าใช้จ่ายสูง c) จะยืนยันได้อย่างไรว่าการประมวลผลข้ามเชนเสร็จสิ้น (b ได้รับเครดิต) มีหลายสถานการณ์ที่ยังไม่ได้ดำเนินการ i. สะพานข้ามโซ่ไม่ได้เริ่มการประมวลผล ii. สะพานข้ามโซ่เริ่มต้นการประมวลผล แต่การตรวจสอบ & ฉันทามติไม่ผ่าน iii. การตรวจสอบบริดจ์ผ่านแต่ไม่มีการทำธุรกรรมเกิดขึ้นบน b-chain iv. มีการทำธุรกรรมบน b-chain แต่ล้มเหลว (เงินไม่เพียงพอหรือกรณีอื่นๆ)

(3) ปัญหาการตรวจสอบหลายลายเซ็น

ส่วนที่กระทบยากที่สุดที่มีปัญหาบ่อยคือปัญหาโค้ดลอจิก a) 3/5 ลายเซ็น ฉันเพิ่งสร้างลายเซ็นที่ไม่ได้อยู่ในรายการหลายลายเซ็น ซึ่งถือว่าเป็น +1 (การแลกเปลี่ยนลูกโซ่) b) ปัญหาของการรวมศูนย์ ซึ่งเป็นการลงนามหลายชื่อ แท้จริงแล้วอยู่ในมือของฝ่ายโครงการ มีความเสี่ยงสูงของการรวมศูนย์ c) วิธีการตรวจสอบลายเซ็น รูปแบบการพัฒนาในห่วงโซ่ที่แตกต่างกัน ส่งผลให้เกิดการละเว้นอย่างหลีกเลี่ยงไม่ได้ เมื่อนักพัฒนาเชื่อมต่อ , ตัวอย่างรูหนอน: ฟังก์ชันลายเซ็นการตรวจสอบบน solana เป็นฟังก์ชันในสัญญาระบบ โดยปกติ ควรเรียกสัญญาระบบและควรเขียนที่อยู่ของสัญญาระบบในรหัส พวกเขาส่งที่อยู่ของ สัญญาระบบเป็นพารามิเตอร์ที่นี่ แฮ็กเกอร์ เมื่อถอนเหรียญที่อยู่สัญญาระบบปลอมจะถูกส่งผ่านและการตรวจสอบลายเซ็นถูกข้ามและเหรียญก็ถูกถอนออกอย่างราบรื่น

(4) การคืนเงิน

ก) ตามที่กล่าวไว้ในข้อ (2)-c มีความเป็นไปได้มากมายสำหรับสถานะของ cross-chain ในกรณีใด ๆ จำเป็นต้องให้วิธีการคืนเงินแก่ผู้ใช้ ตัวอย่างเช่น เมื่อ anyswap ฝากเหรียญ มันจะส่งโทเค็นใด ๆ ก่อน จากนั้นส่งโทเค็นใด ๆ ไปยังผู้ใช้บนเชนเป้าหมาย จากนั้นเบิร์นโทเค็นใด ๆ ของเชนต้นทาง จุดประสงค์ของการทำเช่นนี้คือไม่ว่าปัญหาจะอยู่ที่ใด มี 3 เชน (ต้นทาง เป้าหมาย บริดจ์ข้ามโซ่) และ 4 สินทรัพย์ (โทเค็นดั้งเดิม/โทเค็นใดๆ บนเชนต้นทางและเชนเป้าหมาย) ในกระบวนการนี้ ซึ่งมีแนวโน้มที่จะเกิดปัญหาตรรกะของโค้ด b) Thorchain รั่วไหลออกมาเมื่อวันที่ 23 กรกฎาคม 2021 แฮ็กเกอร์ใช้ปัญหาตรรกะของโค้ดเพื่อสร้างการเติมเงินปลอมจำนวนมหาศาล สะพาน cross-chain ไม่สามารถจัดการได้ ดังนั้น จึงเข้าสู่ตรรกะการคืนเงิน ส่งผลให้แฮ็กเกอร์ได้รับเงินคืนจำนวนมาก

2. ความเสี่ยงด้านความปลอดภัยอื่นๆ

แต่ปัญหาที่สามารถแสดงผ่านกระบวนการทางตรรกะได้นั้นเป็นเพียงปัญหาทางตรรกะทางธุรกิจเท่านั้น ไม่ใช่ทั้งหมด จากมุมมองด้านความปลอดภัย เราควรพิจารณาความเสี่ยงอีกสามประการด้วย

(1) ความเสี่ยงเชิงระบบ

ตัวอย่างเช่น การฝากเงินของ chain เดิมประสบความสำเร็จในตอนเริ่มต้น แล้วย้อนกลับ นี่เป็นปัญหาใหญ่ V God ได้กล่าวถึงวิธีการโอนสินทรัพย์จาก Solana ไปยัง Ethereum แต่ตัวอย่างเช่น เลเยอร์ 2 ซึ่งแบ่งปันการรักษาความปลอดภัยกับ Ethereum เช่น การยกเลิก จะไม่มีปัญหานี้

(2) ความเสี่ยงส่วนหน้า

ก) URL ปลอม เช่น oxdao.fi 0xdao.fi oxdai.fi เป็นต้น ข) การโจมตีแบบ Xss นั่นคือการโจมตีแบบสคริปต์ข้ามไซต์ เป็นการโจมตีแบบแทรกโค้ด เช่น www.xxxx.finance/?params= hackerscode12345 แม้ว่า URL นั้นจะเป็นเว็บไซต์อย่างเป็นทางการ แต่เว็บไซต์นั้นมีรหัสของแฮ็กเกอร์อยู่ หากการพัฒนาส่วนหน้าไม่ใส่ใจในการป้องกัน xss รหัสนี้จะถูกดำเนินการบนหน้าเว็บ ทำให้ผู้ใช้ อนุญาตธุรกรรมการโอนของแฮ็กเกอร์ในการลงนาม ดังนั้น อย่าเปิดลิงก์จากแหล่งที่ไม่รู้จัก c) การโจมตีบริการข้ามไซต์ของ Cors ภายใต้นโยบายแหล่งกำเนิดเดียวกันที่เข้มงวดเบราว์เซอร์จะได้รับอนุญาตให้โหลดเนื้อหาจากไซต์นี้เท่านั้น นั่นคือ เนื้อหาทั้งหมดที่แสดงบนเว็บไซต์ www.xxxx.finance และอินเทอร์เฟซที่เรียกใช้ควรมาจาก xxxx . การเงิน ชื่อโดเมน แต่โครงการปัจจุบันส่วนใหญ่อนุญาตการโทรข้ามไซต์ นั่นคือ ส่วนหน้าของ xxxx สามารถเรียกอินเทอร์เฟซ quickswap และในทางกลับกันซึ่งนำความสะดวกสบายมาสู่การพัฒนาแต่ยังนำความเสี่ยงมาให้อีกด้วย ถ้าฉันไป xxxx.finance เก็บข้อมูลที่ละเอียดอ่อนบางอย่างไว้ในแคชของเบราว์เซอร์ จากนั้นฉันก็ไปที่เว็บไซต์ที่เป็นอันตราย หากนโยบายต้นทางเดียวกันของ xxxx ไม่ถูกจำกัด เว็บไซต์ที่เป็นอันตรายนี้สามารถรับข้อมูลที่จัดเก็บไว้ในแคชของ xxxx ได้อย่างอิสระ

(3) ความเสี่ยงของฟังก์ชันเพิ่มเติม

ชื่อเรื่องรอง

03. บทส่งท้าย

1. จุดประสงค์ของรายงานนี้คือเพื่อช่วยให้ผู้ใช้เข้าใจถึงความเสี่ยงด้านความปลอดภัยของ cross-chain bridges ได้ชัดเจนยิ่งขึ้น และไม่ใช่การแสดงที่เป็นอันตรายถึงความเสี่ยงที่ cross-chain bridges จะถูกโจมตี

2. โซลูชันสะพานข้ามโซ่ของกลไกทนายความเป็นโซลูชันที่มีประสบการณ์ดีที่สุด ขอบเขตการใช้งานที่กว้างที่สุด และต้นทุนต่ำที่สุดอย่างน้อยในตอนนี้ และผลิตภัณฑ์ใด ๆ จะต้องผ่านกระบวนการตั้งแต่มีแผลเป็นไปจนถึงเติบโตเต็มที่ และการโจมตีผลิตภัณฑ์บล็อกเชนมักเป็น "ปัญหาเชิงตรรกะ" คำถามเหล่านี้จะดีขึ้นตามเวลาและประสบการณ์

สแกนรหัส QR เพื่อเข้าร่วมชุมชน ปัญหาผลิตภัณฑ์ โปรดติดตาม Twitter ส่วนตัวของ Jackson เพื่อหารือเกี่ยวกับ @0xOar

เกี่ยวกับ SeerLabs:

SeerLabs (Prophet Labs) เป็นสถาบันชั้นนำในเอเชียที่มุ่งเน้นการบ่มเพาะตลาด blockchain เรามีแนวคิดทางการตลาดที่ล้ำสมัยระดับโลกและแฮ็กเกอร์เพื่อการเติบโตและมุ่งมั่นที่จะช่วยเหลือฝ่ายโครงการและสตาร์ทอัพให้เติบโตอย่างรวดเร็ว ประสบความสำเร็จในการเข้าร่วมบ่มเพาะโครงการมากกว่า 30 โครงการ เช่น Ploygon (MATIC), HoDooi.com, DIA, Paralink, Swingby, XEND Finance, BOSON เป็นต้น

เข้าร่วมกับเรา:

ทวิตเตอร์: https://twitter.com/seerlabs_crypto

การสื่อสารผลิตภัณฑ์: https://twitter.com/0xOar

อีเมลความร่วมมือ: sharon@seerlabs.io

คำเตือนความเสี่ยง: สินทรัพย์ดิจิทัลเป็นเป้าหมายการลงทุนที่มีความเสี่ยงสูง ขอให้ประชาชนทั่วไปดู blockchain อย่างมีเหตุผล สร้างความตระหนักในความเสี่ยง และสร้างแนวคิดสกุลเงินและแนวคิดการลงทุนที่ถูกต้อง

ข้ามโซ่
ยินดีต้อนรับเข้าร่วมชุมชนทางการของ Odaily
กลุ่มสมาชิก
https://t.me/Odaily_News
กลุ่มสนทนา
https://t.me/Odaily_CryptoPunk
บัญชีทางการ
https://twitter.com/OdailyChina
กลุ่มสนทนา
https://t.me/Odaily_CryptoPunk
สรุปโดย AI
กลับไปด้านบน
โซลูชันครอสเชนที่เปลี่ยนแปลงตลอดเวลาจะนำคุณไปสู่การวิเคราะห์ตรรกะการออกแบบของแทร็กคร
ดาวน์โหลดแอพ Odaily พลาเน็ตเดลี่
ให้คนบางกลุ่มเข้าใจ Web3.0 ก่อน
IOS
Android