ข้ามไปยังเนื้อหา

การตัดสเตก (Slashing)

การตัดสเตก (Slashing) คือการลดสเตกตามกฎโปรโตคอล หลังจากผู้ตรวจสอบหรือผู้ดำเนินการทำความผิดที่พิสูจน์และระบุตัวได้ การวิเคราะห์ต้องตรวจเงื่อนไขความผิด หลักฐาน ฐานสเตก สูตรลงโทษ เวลา การมอบหมาย และความเสี่ยงระหว่างถอน โดยไม่เหมารวมว่าการพลาดหน้าที่หรืออัตราร้อยละทุกแบบให้ผลเหมือนกัน

อัปเดต

จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

คำตอบโดยตรง

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

ไม่มีหลักเกณฑ์การลงโทษแบบสากล Ethereum ลงโทษข้อเสนอและการรับรองที่ขัดแย้งกัน แต่จัดการหน้าที่ที่พลาดปกติและการรั่วไหลของความเฉื่อยต่างหาก เครือข่าย Cosmos SDK สามารถกำหนดทั้งการลงโทษการเซ็นซ้ำและการหยุดทำงาน Polkadot แยกความผิด การลงโทษ การปิดใช้งาน และการเปลี่ยนแปลงชื่อเสียง บริการ restaking สามารถเพิ่มข้อผูกพันที่สามารถถูกลงโทษอีกข้อหนึ่ง ซึ่งสัญญา ชุดผู้ดำเนินการ และหน้าต่างการถอนแตกต่างจากเครือข่ายพื้นฐาน อ่านกฎที่ใช้งานอยู่สำหรับเครือข่าย เฟอร์ก ฟังก์ชัน หรือการติดตั้งสัญญาอย่างละเอียด

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

เก็บแนวคิดเหล่านี้แยกออกจากกัน:

  • รางวัลที่พลาดหรือโทษทั่วไป: หน้าที่ขาด ล่าช้า หรือไม่ถูกต้อง แต่ไม่มีการพิสูจน์ว่ามีความผิดที่สามารถถูกลงโทษได้
  • กลไกเมื่อไม่ทำงาน: บทลงโทษเพิ่มขึ้นหรือน้ำหนักโหวตเปลี่ยนระหว่างช่วงที่ไม่สามารถบรรลุ finality เป็นเวลานาน; inactivity leak ของ Ethereum ไม่ใช่การตัดสเตกในตัวมันเอง
  • การตัดสเตก (Slashing): การเปลี่ยนสถานะที่เชนหรือโปรโตคอลรับรอง ซึ่งลดสเตกที่ผูกกับความผิดที่พิสูจน์แล้ว
  • การระงับ ปิดใช้งาน ขับออก หรือห้ามกลับถาวร: ระงับหรือยุติสิทธิ์เข้าร่วม โดยอาจลดสเตกเพิ่มเติมหรือไม่ก็ได้
  • บทลงโทษทางสังคมหรือสัญญา: การกำกับดูแล , ข้อตกลงการให้บริการ, นโยบายประกันภัย, หรือฟอร์กที่ประสานงานกัน กำหนดผลลัพธ์นอกเหนือจากฟังก์ชันการตัดแต้มอัตโนมัติของโปรโตคอลพื้นฐาน

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

วิธีวิเคราะห์การตัดสเตก

1. ระบุชุดกฎและจุดสังเกตให้ชัด

บันทึก network, chain ID, fork version ที่ใช้งานอยู่หรือเวลาทำงาน, บล็อกหรือยุค, การปล่อยให้ลูกค้าหรือข้อกำหนด, และที่อยู่สัญญาที่เกี่ยวข้อง แยกกฎฉันทามติออกจากเงื่อนไขของผู้ให้บริการ staking และอินเทอร์เฟซผู้ใช้ การสอบถามพารามิเตอร์ปัจจุบันและสถานะสุดท้ายเป็นหลักฐานที่แข็งแรงกว่าหน้าแนะนำที่ไม่ได้ระบุวันที่

2. เขียนเงื่อนไขความผิดอย่างแม่นยำ

ตั้งชื่อกฎในรูปแบบที่สามารถปฏิบัติได้: ข้อเสนอสองข้อที่แตกต่างกันโดยผู้ตรวจสอบเดียวกันสำหรับช่องเดียวกัน, double vote, surround vote, การลงคะแนนที่ไม่ถูกต้องซึ่งได้รับการรับรู้โดยโปรโตคอล, หรือ missed > max_missed ภายในหน้าต่างความมีชีวิต อย่าแทนตำแหน่งเงื่อนไขด้วยป้ายชื่อเช่น “พฤติกรรมไม่ดี”, “ออฟไลน์” หรือ “การโจมตี”

3. ตรวจสอบการอ้างอิงและหลักฐาน

ตรวจสอบตัวตนของผู้ตรวจสอบหรือผู้ดำเนินการ ลายเซ็น signing root การแยกโดเมน บริบทของฟอร์ค ความสูงหรือยุค และอายุของหลักฐาน สำหรับความผิดเกี่ยวกับข้อความที่ขัดแย้ง ให้เก็บวัตถุที่ลงนามทั้งสอง สำหรับกฎการมีชีวิต ให้สร้างตัวนับและหน้าต่างของโปรโตคอล การรวมหลักฐานสามารถเกิดขึ้นหลังจากความผิด ดังนั้นให้แยกความแตกต่างระหว่าง infraction time, detection time และ application time

4. ระบุยอดทั้งหมดที่เสี่ยงถูกตัด

ตรวจสอบว่าฐานคือ effective balance, หุ้นที่ผูกไว้ที่ความสูงของการกระทำผิด, หุ้นปัจจุบัน, หุ้นตนเอง, หุ้นที่มอบหมาย, การจัดสรรช่องว่างสำหรับผู้ตรวจสอบ, หรือหุ้นที่กำหนดให้กับ operator set ตรวจสอบขีดจำกัดสูงสุด, ขีดจำกัดต่ำสุด, การปัดเศษ, หน่วยค่า, การถูกตัดก่อนหน้า, การมอบหมายใหม่, และว่าการถอนเงินที่รออยู่ยังสามารถถูกตัดได้หรือไม่

5. คำนวณองค์ประกอบบทลงโทษทุกส่วนใหม่

แยกผลลัพธ์ออกเป็น initial penalty, correlation penalty, ค่าปรับหน้าที่ต่อเนื่อง, รางวัลที่ไม่ได้รับ, ผลกระทบจากการถูกบังคับออก, และรางวัลสำหรับการรายงานหรือการเป็นผู้เปิดโปงกฎเกณฑ์ กฎง่ายๆ แบบกำหนดตายตัวอาจใช้ slash_amount = slashable_stake * slash_fraction; โปรโตคอลสดหลายตัวใช้ฟังก์ชันที่ขึ้นอยู่กับสถานะแทน อย่าใช้เปอร์เซ็นต์หัวข้อกับยอดเงินในกระเป๋าโดยไม่ยืนยันฐานก่อน

6. จัดทำไทม์ไลน์ทั้งหมดและระบุผู้รับภาระขาดทุน

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

7. ตรวจมาตรการควบคุมและกระทบยอดสถานะ

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

ตัวอย่างที่มีการทำงาน

ลายเซ็นที่ขัดแย้งกันสไตล์ Ethereum

สมมติว่า validator V ลงนามใน block header A และ header ที่ต่างกัน B สำหรับ slot = 8 โดยมีลายเซ็นที่ถูกต้องภายใต้บริบท fork ที่เหมาะสมเดียวกัน คู่ดังกล่าวสอดคล้องกับรูปแบบ proposer-equivocation ของ Ethereum; การเสนอที่พลาดใน slot 9 ไม่สอดคล้อง สำหรับการยืนยัน ให้ A = (source = 120, target = 125) และ B = (source = 118, target = 127) เนื่องจาก B ล้อมรอบ A คู่ดังกล่าวมีรูปแบบ surround-vote ป้ายกำกับเพียงอย่างเดียวไม่เพียงพอ: ข้อมูลที่ลงนามจริง, domain, validator index, และการตรวจสอบ slashable-period ต้องผ่านข้อกำหนดปัจจุบัน

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

การคำนวณการขาดทุนจากส่วนแบ่งแบบสัดส่วน

พิจารณาโพรโตคอลตัวอย่างที่มีโทเค็น slashable_stake = 12,500 และ slash_fraction = 0.015 ที่กำหนดไว้ ความสูญเสียของโพรโตคอลคือ:

12,500 * 0.015 = 187.5 tokens.

หากกฎเรียกเก็บจากสเตกที่สนับสนุนทั้งหมดตามสัดส่วน โทเค็น 2,500 ของสเตกผู้ดำเนินการเองจะเสีย 37.5 ขณะที่โทเค็นที่มอบหมาย 10,000 จะเสีย 150 หากสัญญาบริการชดใช้แก่ผู้มอบหมายแต่ไม่ชดใช้แก่ผู้ดำเนินการ การจ่ายนั้นเป็นลูกหนี้และความเสี่ยงเครดิตแยกต่างหาก ไม่เปลี่ยนการตัดสเตกบนเชน และห้ามนำการจัดสรรนี้ไปใช้กับโปรโตคอลที่คุ้มครองผู้มอบหมายหรือใช้ฐานสเตกต่างกัน

หน้าต่างความมีชีวิตแบบสไตล์คอสมอส

สมมติว่าลำดับที่ใช้ Cosmos SDK ได้สอบถามพารามิเตอร์ window = 1,000 และ min_signed = 0.95 จำนวนการพลาดสูงสุดที่อนุญาตคือ:

max_missed = 1,000 - (0.95 * 1,000) = 50.

หากกฎที่ใช้งานอยู่เริ่มทำงานเมื่อ missed > max_missed เกิดขึ้น ในขณะที่ 50 พลาดไปโดยไม่เกินเกณฑ์ แต่ 51 ทำเกินเกณฑ์ เศษส่วนการหัก ระยะเวลาจำคุก การรีเซ็ตตัวนับ และความสามารถในการยกเลิกการจำคุก มาจากพารามิเตอร์ของเครือข่ายที่ใช้งานอยู่และเวอร์ชันโมดูลนั้น นี่เป็นตัวอย่างของเครือข่ายที่กำหนดค่าไว้ ไม่ใช่กฎแบบ proof-of-stake สากล และไม่ใช่วิธีการจัดการเวลาหยุดทำงานของ Ethereum

สูตรความสัมพันธ์ของความผิด

เอกสารที่ได้รับการตรวจสอบของ Polkadot ให้เศษส่วนความไม่แน่นอน min((3 * x / n)^2, 1) ซึ่ง x คือจำนวนผู้กระทำผิด และ n คือจำนวนผู้ตรวจสอบที่ใช้งานอยู่ พร้อมกับ x = 5 และ n = 100:

min((3 * 5 / 100)^2, 1) = 0.0225 = 2.25%.

นำไปใช้กับหน่วย 40,000 ของหุ้นในช่องวาลิเดเตอร์ นั่นคือหน่วย 900 โดยใช้ x = 20 สูตรเดียวกันให้ค่า 36% ไม่ใช่สี่เท่าของ 2.25% ซึ่งแสดงถึงความเสี่ยงของความสัมพันธ์; มันไม่ได้อนุญาตให้ใช้สูตรนั้นกับ Ethereum, เครือข่าย Cosmos, parachain, หรือ runtime Polkadot ที่แตกต่างกันโดยไม่ตรวจสอบกฎปัจจุบัน

ความเสี่ยงและความล้มเหลวในการทบทวน

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

ความเข้าใจผิดทั่วไป

ผู้ตรวจสอบออฟไลน์ทุกคนถูกหักโทษหรือไม่?

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

การตัดสเตกต้องมีหลักฐานเจตนาร้ายหรือไม่?

โดยปกติ กฎอัตโนมัติจะประเมินข้อความที่ลงนาม หลักฐาน การตอบโต้ และสถานะ ไม่ใช่แรงจูงใจ อุบัติเหตุการปฏิบัติงานสามารถตอบสนองต่อเงื่อนไขเดียวกันกับการหลอกลวงโดยเจตนา เจตนาอาจมีความสำคัญต่อการปกครอง การประกันภัย การดำเนินคดี หรือสัญญาบริการ แต่ไม่เกี่ยวข้องกับการเปลี่ยนสถานะเชิงจำ deterministic

ความเสียหายสูงสุดเท่ากับอัตราตัดสเตกที่ประกาศหรือไม่?

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

การเริ่มออกทำให้พ้นความเสี่ยงจากการตัดสเตกทันทีหรือไม่?

ไม่มีข้อกำหนดสากลเช่นนั้น หลักฐานอาจมาถึงล่าช้า ช่วง unbonding มีไว้ส่วนหนึ่งเพื่อคงความรับผิด และการถอนรีสเตกบางแบบยังถูกตัดได้ระหว่างเข้าคิว ต้องตรวจเวลาสุดท้ายที่แต่ละข้อผูกมัดยังตัดสเตกได้ ไม่ใช่ดูเพียงธุรกรรมขอออก

การมอบหมาย การประกัน หรือการฟื้นฟูทางสังคมสามารถลดความเสี่ยงจากการถูกหักเหรียญหรือไม่?

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

หัวข้อที่เกี่ยวข้อง

แหล่งที่มา

การนำทาง

ค้นหาในวิกิ...