﻿---
title: "ผู้ตรวจสอบ"
description: "ผู้ตรวจสอบคือเอกลักษณ์ความเห็นพ้องที่ได้รับการรับรองตามโปรโตคอล ไม่จำเป็นต้องเป็นเพียงเครื่อง ผู้ปฏิบัติการ หรือเจ้าของคนใดคนหนึ่ง วิเคราะห์การยอมรับ คีย์ หน้าที่ น้ำหนักที่มีประสิทธิภาพ รางวัล โทษ การมอบหมาย และการออกจากระบบภายใต้กฎเครือข่ายที่แน่นอน"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ผู้ตรวจสอบ

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

<a id="answer"></a>

## คำตอบโดยตรง

ผู้ตรวจสอบคือเอกลักษณ์ที่โปรโตคอลยอมรับว่าเหมาะสมในการปฏิบัติหน้าที่ตามฉันทามติ เช่น การเสนอ การลงคะแนน การรับรอง หรือการสรุปบล็อก โปรโตคอลเชื่อมโยงเอกลักษณ์นั้นกับคีย์ สถานะ และน้ำหนักการลงคะแนนหรือการเลือก กฎการยอมรับที่ชัดเจน ชุดหน้าที่ และกลไกความรับผิดชอบจะแตกต่างกันไปตามแต่ละเครือข่าย: ระบบพิสูจน์หุ้น (proof-of-stake) มักให้น้ำหนักผู้ตรวจสอบตามหุ้นที่ถูกผูกมัดหรือหุ้นที่มีผล ในขณะที่บางระบบทนความผิดพลาดแบบ Byzantine หรือระบบที่มีสิทธิ์เข้าถึง จะใช้ชุดผู้ตรวจสอบที่กำหนดไว้ล่วงหน้าหรือควบคุม

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

เก็บวัตถุเหล่านี้แยกออกจากกัน:

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

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

<a id="mechanism"></a>

## วิธีวิเคราะห์ผู้ตรวจสอบ

### 1. แก้ไขโปรโตคอลและชุดกฎ

บันทึก `network`, `chain ID`, ฟอร์กหรือการทำงานที่ใช้งานอยู่, บล็อกหรือยุค, การปล่อยไคลเอนต์/ข้อกำหนด, และสัญญาหรือโมดูลการสเตกที่เกี่ยวข้อง คำว่า `validator`, `nominator`, `delegator`, `vote account` และ `operator` ไม่สามารถใช้แทนกันได้ในเครือข่าย Ethereum, Cosmos SDK, Polkadot และ Solana ตรวจสอบพารามิเตอร์แบบสดและสถานะที่สิ้นสุดแทนการโอนกฎจากเครือข่ายอื่น

### 2 แก้ไขตัวตน คีย์ และการควบคุม

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

### 3 ตรวจสอบการเข้าใช้งาน การเปิดใช้งาน และการออก

ระบุข้อกำหนดการสเตกขั้นต่ำหรือการเสนอชื่อ, การทำธุรกรรมการลงทะเบียน, การประกันและคิวการเปิดใช้งาน, การเลือกชุดที่ใช้งาน, ขอบเขตของเซสชันหรือยุค, ขีดจำกัดการเปลี่ยนแปลง, การถอนพันธะ, การออกบังคับ, และการถอนเงินให้เสร็จสมบูรณ์ `Deposited`, `bonded`, `eligible`, `active`, `exiting`, `withdrawable`, และ `withdrawn` เป็นสถานะที่แตกต่างกัน ผู้ตรวจสอบที่อยู่ในคิวอาจไม่ได้เงินใดๆ ในขณะที่ผู้ตรวจสอบที่กำลังออกอาจยังมีหน้าที่หรือความเสี่ยงต่อการถูกปรับ

### 4. แสดงรายการหน้าที่และข้อจำกัดในการลงนาม

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

### 5 ทำซ้ำคำนวณน้ำหนักมีประสิทธิภาพและองค์ประชุม

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

### 6. ประสานเศรษฐศาสตร์และการจัดสรรการขาดทุน

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

### 7 ตรวจสอบการดำเนินงานและยืนยันสถานะบนเชน

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

<a id="example"></a>

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

### ความน่าจะเป็นและความแปรปรวนของงานมอบหมาย

สมมติว่าโปรโตคอลสุ่มผู้ตรวจสอบตามสัดส่วนของน้ำหนักที่มีผล ผู้ตรวจสอบ `V` มีหน่วย `64` จาก `3,200,000` ดังนั้นโอกาสหนึ่งครั้งมีความน่าจะเป็น:

`64 / 3,200,000 = 0.00002 = 0.002%`.

ในโอกาสประกอบภาพประกอบอิสระ `100,000` การมอบหมายที่คาดหวังคือ `lambda = 100,000 * 0.00002 = 2` ภายใต้การประมาณค่า Poisson ความน่าจะเป็นของการไม่มีการมอบหมายคือ:

`P(0) = exp(-2) = 13.5335%`.

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

### ความมีชีวิตแบบถ่วงน้ำหนักไม่ใช่จำนวนผู้ตรวจสอบ

สมมติว่าความสิ้นสุดต้องการน้ำหนักการโหวตรวมมากกว่าสองในสามอย่างเคร่งครัด และสแนปช็อตมีหน่วย `1,000,000` เกณฑ์จำนวนเต็มที่เล็กที่สุดคือ `666,667` หากผู้ตรวจสอบออนไลน์แทนค่า `655,000` ขาดทุนคือ:

`666,667 - 655,000 = 11,667`.

แม้ว่าบันทึกผู้ตรวจสอบ `65` ของ `100` จะออนไลน์ แต่เพียงแค่จำนวนไม่สามารถกำหนดเกณฑ์ได้ ในทางกลับกัน ผู้ตรวจสอบที่มีน้ำหนักสูงเพียงเล็กน้อยอาจตรงตามเกณฑ์ได้ในขณะที่สร้างความเข้มข้นของผู้ปฏิบัติการและโครงสร้างพื้นฐาน

### น้ำตกค่าตอบแทนและค่านายหน้า

สำหรับระยะเวลาหนึ่ง สมมติว่าผู้ตรวจสอบได้รับรางวัลจากโปรโตคอลจำนวน `1,800` หน่วย และค่าธรรมเนียมจำนวน `300` หน่วย เผชิญกับค่าปรับจากโปรโตคอลจำนวน `60` หน่วย และเก็บค่าคอมมิชชั่นจำนวน `15%` หน่วยจาก `2,040` หน่วยที่เหลือ:

`1,800 + 300 - 60 = 2,040`.

`operator_commission = 2,040 * 0.15 = 306`.

`delegator_distribution = 2,040 - 306 = 1,734`.

หากผู้ดำเนินการมีต้นทุนโครงสร้างพื้นฐานและบุคลากร `240` กำไรสุทธิก่อนภาษีในตัวอย่างคือ `306 - 240 = 66` การคำนวณนี้สมมติว่าสัญญาคิดค่าคอมมิชชั่นหลังหักค่าปรับสำหรับรายได้ทั้งสองประเภท เชนหรือผู้ให้บริการอื่นอาจใช้ฐาน เวลา การปัดเศษ หรือการจัดสรรขาดทุนที่แตกต่างกัน

### บันทึกเทียบกับการควบคุมทั่วไป

นักสำรวจแสดงบันทึกผู้ตรวจสอบ `120` แต่ละรายการมีหน่วยที่มีผลบังคับใช้ `32` สำหรับน้ำหนักรวม:

`120 * 32 = 3,840`.

การสอบสวนจับคู่บันทึก `60` กับผู้ปฏิบัติงาน A, `40` กับ B, และ `20` กับ C น้ำหนักที่มีประสิทธิภาพของพวกเขาคือ `1,920`, `1,280`, และ `640` หรือ `50%`, `33.3333%`, และ `16.6667%` อินเทอร์เฟซรายงานตัวตนของผู้ตรวจสอบ 120 แต่มีเพียงผู้ปฏิบัติงานที่รู้จักสามราย การวิเคราะห์เพิ่มเติมควรรวมถึงการจัดกลุ่มผู้เซ็นร่วม, ลูกค้า, คลาวด์, และเจ้าของผลประโยชน์; จำนวนบันทึกไม่ใช่ตัววัดการกระจายอำนาจ

<a id="risks"></a>

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

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

<a id="misconceptions"></a>

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

### โหนดเต็มทุกตัวคือผู้ตรวจสอบหรือไม่?

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

### ผู้ตรวจสอบทำการตรวจสอบธุรกรรมโดยใช้ดุลยพินิจส่วนตัวหรือไม่?

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

### การมีบันทึกผู้ตรวจสอบมากขึ้นหมายถึงการกระจายอำนาจมากขึ้นเสมอหรือไม่?

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

### ผลตอบแทนจากการสเตกที่โฆษณาเป็นกำไรของผู้ดำเนินการผู้ตรวจสอบใช่หรือไม่?

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

### ผู้ปฏิบัติงานสามารถออกและถอนตัวได้ทันทีเมื่อความเสี่ยงเพิ่มขึ้นหรือไม่?

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

<a id="related"></a>

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

- [การพิสูจน์ความเป็นเจ้าของเหรียญ](/th/crypto/proof-of-stake/)
- [การตัดสเตก](/th/crypto/slashing/)
- [การสเตก](/th/crypto/staking/)
- [คิวออกและถอน ผู้ตรวจสอบ](/th/crypto/validator-exit-withdrawal-queue/)
- [อัตวิสัยอ่อนแอ](/th/crypto/weak-subjectivity/)

<a id="sources"></a>

## แหล่งที่มา

- [กลไกฉันทามติแบบพิสูจน์สิทธิ์การถือครอง](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (เข้าถึง: 2026-08-19)
- [กุญแจแบบพิสูจน์การถือหุ้น](https://ethereum.org/developers/docs/consensus-mechanisms/pos/keys/) - Ethereum.org (เข้าถึง: 2026-08-19)
- [ข้อกำหนดฉันทามติ Ethereum: Honest Validator](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (เข้าถึง: 2026-08-19)
- [Cosmos SDK โมดูล x/staking](https://docs.cosmos.network/sdk/v0.53/build/modules/staking/README) - Cosmos SDK (เข้าถึง: 2026-08-19)
- [การรันโนด](https://docs.cosmos.network/sdk/latest/node/run-node) - Cosmos SDK (เข้าถึง: 2026-08-19)
- [Validator Requirements](https://docs.polkadot.com/node-infrastructure/run-a-validator/requirements/) - Polkadot Developer Docs (เข้าถึง: 2026-08-19)
- [Stake Accounts](https://solana.com/docs/references/staking/stake-accounts) - Solana Foundation (เข้าถึง: 2026-08-19)
- [ภาพรวมเทคโนโลยีบล็อกเชน](https://doi.org/10.6028/NIST.IR.8202) - NIST (เข้าถึง: 2026-08-19)

Source: https://wiki.fcontext.com/th/crypto/validator/index.mdx
