🔑 이더리움 솔로 스테이킹, 32개 미만이면 검증자를 켤 수 없나요

이더리움 솔로 스테이킹은 32개 미만으로도 예치 자체는 할 수 있지만, 그 검증자는 켜지지 않아요. 이더리움 합의 규격은 한 번 예치할 수 있는 최소 금액을 1 ETH로, 검증자가 활성화되는 최소 잔고를 32 ETH로 따로 정해 두었어요. 32개보다 적게 넣으면 예치 서명이 맞는 경우 검증자 목록에 기록과 잔고는 생기지만 활성화 대기열에 들어갈 자격이 없어서, 같은 검증자 키로 더 예치해 유효 잔고가 32 ETH에 이를 때까지 그대로 있어요. 32개를 넘게 넣는 쪽은 인출 자격 증명에 따라 달라요. 일반 인출(0x01) 검증자는 유효 잔고가 32 ETH에서 멈추고 넘는 잔고는 자동으로 인출 주소로 나가며, 복리(0x02) 검증자는 유효 잔고를 2048 ETH까지 인정받아요.

먼저 요약하면 이래요.

• 한 번에 넣을 수 있는 최소 금액: 1 ETH예요. 규격의 예치 컨트랙트 문서는 예치 금액이 MIN_DEPOSIT_AMOUNT 이상이어야 한다고 적었고, 그 값이 1 ETH예요.
• 검증자가 켜지는 최소 잔고: 32 ETH예요. 활성화 대기열 자격은 유효 잔고가 MIN_ACTIVATION_BALANCE(32 ETH) 이상일 때만 생겨요.
• 32개 미만으로 넣으면: 검증자 기록은 만들어지지만 대기열 자격이 없어요. 같은 키로 추가 예치해 유효 잔고가 32 ETH가 되면 그때부터 대기열에 들어가요.
• 32개를 넘게 넣으면: 0x01은 유효 잔고 상한이 32 ETH, 0x02는 2048 ETH예요. ethereum.org 한국어 페이지도 「검증자당 최소 32 ETH, 최대 2048 ETH」라고 적었어요.
• 16 ETH 선: 활성 검증자의 유효 잔고가 16 ETH 이하로 내려가면 규격이 종료 절차를 시작해요.

이 글은 2026년 10월 26일 오후 6시 21분(한국 시각)에 이더리움 합의 규격 저장소(ethereum/consensus-specs, master 브랜치)의 phase0·capella·electra·fulu 비컨체인 문서와 예치 컨트랙트 문서, 메인넷 설정 파일, 그리고 ethereum.org 한국어 홈 스테이킹 페이지(2026년 8월 17일 마지막 업데이트)를 내려받아 읽고 정리했어요. 상수는 파일의 표에서, 조건은 함수 본문에서 옮겼어요. 활성화 대기열의 실제 길이나 대기 시간, 보상률, 검증자 수는 재지 않았고, 특정 클라이언트나 스테이킹 업체를 고르는 글도 아니에요. 코인을 사거나 팔라고 권하는 글이 아니에요.

이 글이 읽은 자료

규격 저장소는 바뀐 부분만 단계별 폴더에 적는 방식이에요. 그래서 1 ETH 최소 예치액은 phase0 문서에, 32 ETH 활성화 잔고와 2048 ETH 상한은 electra 문서에 있어요. 메인넷 설정 파일에는 electra 규칙이 2025년 5월 7일, 그다음 fulu 규칙이 2025년 12월 3일(협정 세계시 기준, 한국 시각으로는 12월 4일 오전)부터 메인넷에 적용됐다고 적혀 있어서, 이 글의 규칙은 2026년 10월 26일 현재 메인넷에서 쓰이는 규칙이에요. 저장소의 electra 문서가 마지막으로 고쳐진 날은 2026년 10월 6일이었어요.

숫자 다섯 개로 보는 규칙

여기서 헷갈리기 쉬운 것은 잔고와 유효 잔고가 다르다는 점이에요. 잔고는 검증자가 실제로 가진 ETH이고, 유효 잔고는 규격이 활성화 조건과 보상 계산에 쓰는 값이에요. 유효 잔고는 1 ETH 단위로 내린 값이라서, 31.9 ETH를 한 번에 예치하면 유효 잔고는 31 ETH로 잡혀요. 그리고 자격 증명별 상한(0x01은 32 ETH, 0x02는 2048 ETH)을 넘지 못해요.

인출 접두어는 세 가지예요.

electra 문서의 상한 함수는 자격 증명이 0x02이면 2048 ETH를, 그렇지 않으면 32 ETH를 돌려줘요. 0x01 검증자에게 32 ETH가 활성화 최소값이자 상한이 되는 이유가 여기 있어요.

32개 미만으로 예치하면 어떻게 되나요

규격이 예치를 처리하는 순서를 따라가 보면 이래요.

1. 예치는 먼저 대기 예치 목록에 들어가요. 지금 쓰이는 fulu 문서의 예치 처리 함수는 예치가 확정된 블록에 있는지, 이번 에포크에 처리한 예치가 16건을 넘지 않았는지, 이번 에포크의 처리 한도 안에 드는지를 보고 차례대로 적용해요.
2. 처음 보는 검증자 키라면 예치 서명을 확인해요. 규격 주석은 이 서명을 예치 컨트랙트가 확인하지 않는다고 적었어요. 서명이 맞으면 검증자 목록에 새 검증자를 추가하고, 맞지 않으면 새 검증자를 만들지 않고 넘어가요.
3. 새 검증자는 활성화 자격 시점, 활성화 시점, 종료 시점, 인출 가능 시점이 모두 「아주 먼 미래」로 정해진 채 시작해요. 유효 잔고는 예치액을 1 ETH 단위로 내린 값과 상한 중 작은 값이에요.
4. 에포크마다 도는 등록 갱신 함수가 대기열 자격을 봐요. electra 문서의 조건은 두 가지예요. 아직 대기열 자격 시점이 정해지지 않았고, 유효 잔고가 MIN_ACTIVATION_BALANCE(32 ETH) 이상이어야 해요. 둘 다 맞으면 다음 에포크를 대기열 자격 시점으로 적어요.
5. 그 자격 시점이 확정된 체크포인트까지 오고 아직 활성화되지 않은 검증자에게 활성화 시점이 정해져요.

그래서 31 ETH를 넣은 검증자는 3번까지는 진행돼서 목록에 있고 잔고도 31 ETH이지만, 4번의 32 ETH 조건에서 멈춰요. 이 글이 읽은 규격 문서에서 활성화 시점을 정하는 곳은 이 등록 갱신 함수뿐이었고, 32 ETH 미만인 채로 활성화하는 다른 조건은 찾지 못했어요. 앞으로 나아가는 방법은 같은 검증자 키로 다시 예치하는 것이에요. 이미 목록에 있는 키로 온 예치는 서명을 다시 확인하지 않고 잔고에 더해져요.

1 ETH만 더 넣으면 되나요

여기에 함정이 하나 있어요. 유효 잔고는 잔고가 조금 움직일 때마다 바로 따라가지 않아요. electra 문서의 유효 잔고 갱신 함수는 0.25 ETH를 한 칸으로 잡고, 잔고가 유효 잔고보다 1.25 ETH(다섯 칸)를 넘게 많아졌거나, 0.25 ETH(한 칸)를 넘게 적어졌을 때만 유효 잔고를 다시 계산해요.

이 표는 규격의 함수와 상수로 이 글이 직접 계산한 예시예요. 정리하면, 유효 잔고가 31 ETH로 잡힌 검증자는 잔고가 32.25 ETH를 넘어야 유효 잔고가 32 ETH로 올라가요. 부등호가 「넘어야」라서 정확히 32.25 ETH로는 부족해요. 반대로 처음부터 32 ETH를 한 번에 넣으면 유효 잔고가 바로 32 ETH로 잡혀서 이 문제가 생기지 않아요.

활성화 전에 넣은 ETH를 꺼낼 수 있나요

이 글이 읽은 함수 안에서는 활성화 전 검증자의 잔고를 꺼내는 길을 찾지 못했어요. 검증자 키로 서명하는 자발적 종료와 인출 주소에서 보내는 종료·부분 인출 요청은 모두 조건 가운데 하나로 「활성 검증자일 것」을 요구해요. 자동 전액 인출은 인출 가능 시점에 이르러야 하는데, 활성화 전 검증자는 그 시점이 아주 먼 미래로 남아 있어요. 자동 부분 인출은 유효 잔고가 상한(0x01은 32 ETH)과 같아야 해서 31 ETH 검증자는 해당하지 않아요. 규격 전체를 다 읽었다는 뜻은 아니고, 32 ETH 미만 검증자를 위한 별도 환불 절차는 읽은 문서에 적혀 있지 않았어요.

32개보다 많이 넣으면 어떻게 되나요

일반 인출(0x01) 검증자

0x01 검증자는 유효 잔고 상한이 32 ETH예요. 그래서 40 ETH를 넣어도 유효 잔고는 32 ETH로 잡혀요. electra 문서의 자동 부분 인출 조건은 0x01이나 0x02 자격 증명이 있고, 유효 잔고가 상한과 같고, 잔고가 상한을 넘을 때예요. 이때 상한을 넘는 만큼이 인출 주소로 나가요. ethereum.org 한국어 페이지도 0x01 검증자는 「유효 잔고는 32 ETH로 제한되며, 이를 초과하는 잔고는 며칠마다 자동으로 인출 주소로 전송됩니다」라고 적었어요.

복리(0x02) 검증자

0x02 검증자는 유효 잔고를 2048 ETH까지 인정받아요. ethereum.org 페이지는 「최소 32 ETH를 초과하는 모든 정수 ETH에 대해 보상을 얻으므로 32의 배수뿐만 아니라 40 ETH와 같이 유연한 금액을 스테이킹할 수 있습니다」라고 설명하고, 2048 ETH를 넘는 잔고만 자동으로 나간다고 적었어요. 그 아래 금액을 꺼내려면 인출 주소에서 부분 인출을 요청해야 해요.

electra 문서의 인출 요청 함수는 부분 인출 요청을 0x02 자격 증명에만 허용해요. 조건은 요청 주소가 자격 증명에 적힌 주소와 같고, 활성 상태이고, 종료를 시작하지 않았고, 활성화 뒤 256 에포크가 지났고, 유효 잔고가 32 ETH 이상이며, 잔고가 32 ETH와 이미 대기 중인 인출액의 합보다 많을 때예요. 꺼낼 수 있는 양은 요청한 금액과 「잔고에서 32 ETH와 대기 중인 인출액을 뺀 값」 중 작은 쪽이에요. 부분 인출로는 32 ETH 아래로 내려갈 수 없는 구조예요.

0x01에서 0x02로 바꾸기

electra 문서에는 0x01 검증자를 0x02로 바꾸는 요청이 있어요. 인출 주소에서 원본과 대상을 같은 검증자로 적어 보내는 통합 요청이고, 원본이 0x01이며 활성 상태이고 종료를 시작하지 않았을 때 받아들여져요. 바뀌면 자격 증명 첫 바이트가 0x02가 되고, 그때 잔고가 32 ETH를 넘으면 넘는 부분은 잔고에서 빠져 대기 예치로 다시 들어가요. ethereum.org 페이지는 이 전환이 「완전히 종료하고 다시 예치하지 않는 한 되돌릴 수 없습니다」라고 적었어요. 이 글은 전환 절차를 실제로 해 보지 않았어요.

16 ETH 선과 종료

에포크마다 도는 등록 갱신 함수에는 퇴출 조건도 들어 있어요. 활성 검증자의 유효 잔고가 EJECTION_BALANCE(16 ETH) 이하이면 종료를 시작해요. ethereum.org 페이지는 네트워크 완결이 멈추는 극단적인 경우를 설명하며, 오프라인 검증자의 잔고가 16 ETH에 이를 때까지 줄어들다가 그 시점에 검증자 풀에서 자동으로 퇴출된다고 적었어요. 32 ETH가 들어가는 문턱이라면 16 ETH는 활성 검증자가 밀려나는 선이에요.

스스로 끝내고 싶을 때는 두 길이 있어요. 검증자 키로 서명하는 자발적 종료와 인출 주소에서 보내는 전액 종료 요청이에요. 두 경우 모두 활성화 뒤 256 에포크가 지나야 하고, 대기 중인 부분 인출이 없어야 해요. ethereum.org 페이지는 인출 주소에서 종료를 직접 걸 수 있어서 「서명 키를 분실하더라도 자금을 복구할 수 있습니다」라고 적었어요. 이 설명에는 인출 주소가 설정돼 있다는 전제가 붙어요. 같은 페이지는 인출 주소를 설정하지 않은 초창기 스테이커는 인출하기 전에 인출 자격 증명을 업데이트해야 한다고 적었고, capella 문서에 0x00을 0x01로 바꾸는 작업이 있어요.

활성화 처리 한도는 규칙으로만

검증자가 몇 개든 한 에포크에 바로 다 켜지지는 않아요. electra 문서의 처리 한도 함수는 한 에포크에 들어오고 나가는 잔고의 양을 「전체 활성 잔고를 65536으로 나눈 값과 128 ETH 중 큰 값」으로 잡고, 활성화·종료에 쓰는 몫은 그 값과 256 ETH 중 작은 값으로 묶어요. 대기 예치도 한 에포크에 16건까지만 처리해요. ethereum.org 페이지는 새 검증자가 활성화 대기열을 거치며 그 길이가 수요에 따라 달라진다고 적었어요. 이 글은 대기열의 실제 길이와 대기 시간을 재지 않았어요.

32개가 없을 때 ethereum.org가 적은 다른 길

ethereum.org 한국어 페이지는 32 ETH 미만이면서 노드를 운영할 하드웨어와 기술이 있는 사람에게 일부 스테이킹 프로토콜이 풀 스테이커의 ETH와 검증자를 매칭해 준다고 적었어요. 더 적은 보증금을 예치하고 자기 기기에서 검증자를 돌리면 프로토콜이 나머지 스테이크를 채우는 방식이고, 페이지는 이 경우 검증자가 프로토콜의 스마트 컨트랙트와 거버넌스, 성능 규칙에 따라 움직여 직접 스테이킹과는 다른 신뢰 구조를 갖는다고 설명했어요. 풀 스테이킹은 소액으로도 참여할 수 있다고 적었어요. 이 글은 특정 프로토콜이나 업체를 비교하지 않았어요. 위탁형 스테이킹의 구조는 Lido와 Rocket Pool의 차이를 정리한 글에, 스테이킹 일반의 보상과 위험은 스테이킹의 원리와 위험을 정리한 글에 있어요.

정리

이어서 볼 글

스테이킹을 끝낼 때 기다려야 하는 기간을 체인별로 정리한 내용은 언스테이킹 기간을 정리한 글에 있어요. 이더리움의 지분증명이 공격을 어떻게 막는지는 51% 공격의 한계를 이더리움 문서로 읽은 글에서 볼 수 있어요.

이 글이 다루지 않은 것

• 활성화 대기열과 종료 대기열의 실제 길이, 대기 시간, 보상률, 검증자 수는 재지 않았어요.
• 클라이언트 설치, 키 생성, 예치 화면 같은 실제 진행 절차는 다루지 않았고, 특정 클라이언트나 스테이킹 업체를 고르지 않았어요.
• 0x01에서 0x02로 바꾸는 요청과 검증자 통합은 규격의 조건만 옮겼고 실제로 해 보지 않았어요.
• 31 ETH 예시는 이 글이 규격의 함수와 상수로 계산한 것이에요. 실제 검증자로 확인한 사례가 아니에요.
• 메인넷 적용 날짜가 정해지지 않은 규격 파일은 읽지 않았어요.
• 스테이킹 보상의 세금은 다루지 않았어요.

모든 내용은 2026년 10월 26일 오후 6시 21분(한국 시각)에 내려받은 ethereum/consensus-specs 저장소 master 브랜치의 문서와 설정 파일, ethereum.org 한국어 홈 스테이킹 페이지 기준이에요. 규격과 안내 페이지는 바뀔 수 있어요.

이 글은 정보 제공 글이며 매매 권유나 투자 자문이 아니에요. 가상자산은 변동성이 크고 원금 손실 위험이 있어요. 스테이킹에는 슬래싱과 비활동 페널티 같은 잔고 감소 위험도 있어요. 투자 판단과 그 결과에 대한 책임은 본인에게 있어요.