零基础搭建ETH中转节点：Python实现Stratum代理与抽水原理详解

简介面向以太坊矿工与零基础运维人员这份说明文档用于指导从零搭建带抽水功能的ETH中转节点解决自建矿池代理与算力抽取的需求。资源由单个docx文档组成压缩包约265KB内容以分步骤截图配合文字的形式呈现涵盖Windows系统下minerProxy软件的下载解压、云服务器复制运行、config.yml自动生成、后台18888端口访问与Token密钥登录等操作。文中以鱼池为例展示如何新建端口、设置抽水模式并定义抽水1%算力流向同时对开启SSL协议后矿机采用stratumssl连接格式、本地端口不可重复、防火墙安全组放行端口等关键事项做出明确提醒并建议用户修改默认后台端口以防暴露。文档整体结构紧凑、图文步骤清晰可直接对照执行适合零基础读者边看边操作。目前已有1214人学习下载可作为搭建中转节点的入门参考与排错手册。1. ETH中转节点是什么一个自带抽水的Stratum网关“零基础搭建ETH中转节点”听着吓人但拆开看就是一个放在矿机和矿池之间的代理层。矿机不直接连矿池而是连到你的服务器你再把它连接到的上游矿池期间能统一监控每台矿机状态还能按比例抽取一部分算力作为服务费——也就是抽水。以太坊转PoS后ETH本身的PoW挖矿停了但ETC和不少分叉链依然使用同一种Stratum协议这套走法照样能用。适合有若干台矿机想集中管理的个人或者想给周边矿友提供接入服务的技术人员不是研究共识算法的开发者也不需要你有运维大厂的底子。这篇文章没有抽象概念从协议流程到Python转发器再到抽水参数和踩坑一条线走通。2. 原理与选型抽水的三种实现方式以及我为什么推荐按份额转发2.1 先搞懂ETH挖矿的Stratum协议连接、任务、提交矿机和矿池之间的通信是TCP长连接每行一条JSON消息这个协议叫Stratum。和HTTP那种一问一答不同矿池可以主动下发任务矿机也可以随时提交结果所以整个交互是异步的。流程可以拆成五步矿机连上后先发mining.subscribe告诉矿池自己是什么类型的矿机想订阅任务矿池返回一个订阅ID和协议版本。然后矿机发mining.authorize附上自己的挖矿地址和worker名代表“我要在这个账号下干活”。矿池返回true之后会主动推一条mining.set_difficulty告诉矿机当前验证份额的难度紧接着是mining.notify这才是真正的“作业”矿池把区块头信息和难度塞给矿机矿机开始用这个header算nonce。矿机一旦找到一个符合难度的nonce就发mining.submit提交。矿池验证通过后返回一个JSON响应矿机会继续请求下一条notify。这里最关键的点是矿池只认mining.submit中满足当前难度的share并且把它记账到mining.authorize时指定的账户上。每一条share的权重和当前难度、你设置的真实算力相关矿池最后的收益就是这些share的累计。所以“中转节点”想抽水本质就是“想办法让一部分share不上报给矿池”。可矿池不是傻子你不上报它自然不给你钱。真正的抽水必须把这些被抽掉的份额变成你自己的收益下文会展开。2.2 抽水的三种实现方式改难度、改地址、按份额转发第一种思路是改难度。矿机提交share时原本需要满足矿池设定的难度中转节点可以故意把一个“难度更高”的任务发给矿机比如矿池要求5000你发给矿机难度10000。矿机在更高难度下找出份额的概率更低于是提交的share数量变少算力看起来就下降了。这部分“少出来的”算力并没有变成你的收益矿池也只看到了更少的share所以这个方法只适合做实时的算力限制不适合抽水。第二种思路是改地址。中转节点在转发mining.authorize时把矿机传入的钱包地址替换成你自己的钱包地址然后向矿池发起一条连接。这样矿池会把所有份额记录到你的地址下矿机的贡献全部归你然后你在线下去跟矿工结账。这种方案看起来完整但实现复杂度高矿池来的mining.notify是广播消息所有矿机都需要收到你需要维护一个连接池把一条上游消息fan-out给所有矿机同时每个矿机的作者名还不能一样否则矿池后台无法区分。适合有开发能力、想做大型中转站的人。第三种是按份额转发也是我推荐零基础采用的做法。你仍然用矿工的连接和矿池建立连接但矿工的mining.submit不是直接转发而是先经过一个过滤器按比例比如2%让一部分submit被“吞掉”。被吞的不转发给矿池但你给矿机返回一个result:true。矿机以为份额被接受了实际上矿池根本没收到这一份。长跑下来矿池后台显示的算力便比实际矿机算力低2%——这部分就是你要抽的水。但严格说被吞掉的份额依然没有变成你的收益只是让矿工少赚了。如果你自己运营想在抽水时同时把这部分份额算到自己头上就需要上游连接使用你自己的钱包地址再把抽掉的份额转发到一个自己控制的矿池账号。我的建议是第一步先把“吞份额伪造响应”做通后面再在转发逻辑里加一个双路上游把被抽的份额重新提交到自己的地址。方案实现难度风险适合人群改难度低矿池无法识别但矿机端显示异常临时限制算力不建议用于抽水改地址共享连接高需要处理消息广播、worker映射有开发经验的中转站按份额转发丢弃低可精确控制但被抽份额需要额外的转发通道才能真正成为你的收益零基础起步首选2.3 选型自己写Python转发器而不是套用开源矿池项目网上能搜到不少“矿池源码”比如open-ethereum-pool这类PHPNode项目。但那些是完整矿池包含HTTP钱包服务、数据库、worker统计、支付系统对零基础来说太重。更要命的是完整矿池通常要求你掌握Redis、MariaDB、多个回调接口一旦配置错误整个连接都会崩。而我要做的只是一个代理层核心只有“读一行JSON改参数转发到另一个TCP连接”。语言上我选Python的asyncio理由很直接它处理并发TCP连接非常省事代码能控制在几百行以内不需要引入任何框架。你只需要记住async def和await就能写出非阻塞的双向转发器。相比Go或NodePython对新手排错最友好而且测试时可以直接在终端打印消息内容。模块结构我建议分成三层网络层监听本地端口接受矿机连接。转发层读矿机消息、读矿池消息双向写回。抽水层只拦mining.submit按比例决定是原样转发还是伪造响应。这样做的好处是后续要调整抽水算法不用碰网络层。我一般会先写一个完全没有抽水逻辑的纯转发器跑通一台矿机确认矿池能看到真实算力然后再在转发层里插入过滤函数逐步调试。3. 从零搭建一个可运行的Python转发器与抽水参数3.1 准备环境服务器、Python版本、端口开放你需要一台有公网IP的Linux服务器1核1G就足够毕竟这个代理本身不参与挖矿计算。系统建议Ubuntu 20.04或Debian 11自带Python 3.8及以上版本asyncio是内置库不需要pip安装任何第三方包。唯一要做的系统级操作是开放端口我习惯用3333这个高位端口避免顶着22、443这些常用端口被扫描爆破。sudo apt update sudo apt install -y python3 sudo ufw allow 3333/tcp上面代码里ufw allow 3333/tcp是放行TCP入站连接。如果你用的是阿里云/腾讯云还要在安全组规则里同时放行这个端口这一步很多人忘了导致矿机连不上。检查方式在服务器上用ss -lntp | grep 3333看端口是否在监听如果显示0.0.0.0:3333说明Python服务已经起来了再在矿机端用telnet 你的服务器IP 3333测试端口通不通。3.2 实现最小Stratum转发器注册、替换钱包、双向转发先给出一个可合并运行的代码骨架。下面的类负责管理一个矿工连接到上游矿池的全过程每个矿工连接进来都会实例化一个ProxyHandler各自维护自己的上游连接。import asyncio import json PROXY_HOST 0.0.0.0 PROXY_PORT 3333 POOL_HOST eth.example.com # 换成你实际所要接入的矿池地址 POOL_PORT 4444 # 换成上游矿池端口 POOL_WALLET 0xYourPoolWallet # 换成你的抽水钱包地址 DROP_RATE 0.02 # 抽水比例2% class ProxyHandler: def __init__(self, miner_reader, miner_writer): self.miner_reader miner_reader self.miner_writer miner_writer self.pool_reader None self.pool_writer None self.share_count 0 # 当前矿工的份额计数 self.drop_interval int(1 / DROP_RATE) # 每50个份额丢掉1个 async def start(self): self.pool_reader, self.pool_writer await asyncio.open_connection( POOL_HOST, POOL_PORT) await asyncio.gather( self.forward_miner_to_pool(), self.forward_pool_to_miner() ) async def forward_miner_to_pool(self): while True: data await self.miner_reader.readline() if not data: break line data.decode().strip() if not line: continue await self.route_miner_message(line) async def forward_pool_to_miner(self): while True: data await self.pool_reader.readline() if not data: break self.miner_writer.write(data) # 矿池消息原样转发给矿机 await self.miner_writer.drain()start()方法里做了两件事建立上游矿池连接然后用gather同时启动两个“方向”的事件循环。forward_miner_to_pool是读取矿机发来的每行JSON准备好之后进入路由函数forward_pool_to_miner则很简单矿池发来的任何消息mining.notify、mining.set_difficulty、mining.submit的响应只要不经过过滤一律原样写回给矿机。3.3 抽水逻辑实现替换授权地址、按百分比吞份额在3.2的骨架里route_miner_message还没有定义。这一节把它补完整真正实现抽水。核心逻辑是对mining.authorize替换钱包地址对mining.submit进行间隔抽样。async def route_miner_message(self, line): try: msg json.loads(line) except json.JSONDecodeError: return method msg.get(method) if method mining.authorize: # 关键点1把矿机原有的钱包地址替换成你的抽水钱包地址 original_worker msg[params][0] if . in original_worker: suffix original_worker.split(., 1)[1] msg[params][0] f{POOL_WALLET}.{suffix} else: msg[params][0] POOL_WALLET self.pool_writer.write((json.dumps(msg) \n).encode()) await self.pool_writer.drain() elif method mining.submit: # 关键点2按比例吞掉部分份额 self.share_count 1 if self.share_count % self.drop_interval 0: fake_resp {id: msg[id], result: True, error: None} self.miner_writer.write((json.dumps(fake_resp) \n).encode()) await self.miner_writer.drain() else: self.pool_writer.write((json.dumps(msg) \n).encode()) await self.pool_writer.drain() else: # 其他消息如mining.subscribe原样转发 self.pool_writer.write((json.dumps(msg) \n).encode()) await self.pool_writer.drain()对mining.authorize的处理是必备动作。如果矿机直接用自己的钱包地址连接矿池上游矿池会记到这个地址上但你的目的是让所有份额都先归到你的地址名下。这里original_worker形如0x矿工钱包.worker1替换后变成0x你的钱包.worker1前缀变了但后缀还在这样矿池后台仍能看到不同worker名。抽水间隙drop_interval直接用1 / DROP_RATE计算比如DROP_RATE0.02则drop_interval50表示每收到50个submit就吞掉第50个吞掉的这部分需要你伪造一个result:true响应给矿机否则矿机等不到响应会反复重发造成大量重复提交。代码里的fake_resp使用的是矿机消息里的id因为矿机与矿池之间的id是同步的矿机发mining.submit时id是3矿池返回时也应该是3。伪造响应保证了矿机认为自己的份额被接受。当然你需要自己在后台记录被吞的份额数和对应的钱包后续对账才能算出实际抽水量。3.4 把服务跑起来启动脚本和加密日志上面代码组装好后保存为eth_pool_proxy.py。启动命令很简单python3 eth_pool_proxy.py但我强烈建议你写成systemd服务不要直接挂个nohup否则服务器一重启你就要手动启动矿机会全部离线。创建一个服务文件sudo tee /etc/systemd/system/eth-proxy.service /dev/null EOT [Unit] DescriptionETH Stratum Proxy Afternetwork-online.target [Service] WorkingDirectory/opt/eth-proxy ExecStart/usr/bin/python3 /opt/eth-proxy/eth_pool_proxy.py Restartalways RestartSec5 [Install] WantedBymulti-user.target EOT sudo systemctl daemon-reload sudo systemctl enable --now eth-proxy这里的Restartalways是零基础最容易漏的。代理进程只要因为内存波动或上游断连而退出systemd会在5秒后自动拉起矿机重连一次就能接着跑不需要人工干预。日志我建议直接用journalctl -u eth-proxy -f查看不需要额外配日志文件。4. 避坑指南连接失败、掉线、份额被拒的六个常见坑4.1 现象矿机显示已连接但几秒后立刻断开原因矿机发完mining.subscribe后没有在合理时间内收到矿池的响应。这多半是代理只做了“单向转发”矿池传回来的消息没有返回给矿机。我之前调过一版只写了miner_forward忘了pool_forward矿机就一直停在“订阅中”直到矿端软件判定超时。解决确认forward_pool_to_miner已经从上游readline()并写到矿机。你可以把这两个函数分别打上print日志看交互顺序是否和2.1节描述的完全一致。4.2 现象授权成功但矿机迟迟不收任务原因mining.authorize返回true后矿池会立刻下发mining.set_difficulty和mining.notify。这些消息都是矿池主动推送的如果你在forward_pool_to_miner里写了“只响应不推送”的逻辑就会把消息丢掉。解决矿池向矿机推消息时不需要考虑请求ID。mining.notify的id是null你直接原样转发即可不要做任何JSON解析或过滤。同时确认你没有在notify上走抽水逻辑否则会清空所有任务。4.3 现象所有提交的份额都被矿池拒绝算力为0原因典型的一个是我在3.3节强调的mining.authorize没有替换钱包地址。矿机用它自己的钱包地址提交份额矿池校验后不认账。另一个原因是矿池可能对worker名做了格式限制比如不允许下划线你却保留了一个不合法的后缀。解决在授权时打印一下替换后的完整字符串确认格式为0x你的钱包.worker名。worker名建议只用字母、数字和短横线不要用中划线或空格。另外有些矿池要求mining.subscribe必须在authorize之前如果你在代码里反了顺序也会导致全部份额被拒。4.4 现象抽水比例设置2%但矿工在矿池后台的算力波动达30%原因固定间隔抽样带来的周期性波动。每50个份额吞一个吞掉那一下正好落在一个难度较高的任务上矿工的这一小段算力就瞬间掉一半从5分钟窗口看会非常明显。解决把固定间隔改成均匀随机抽样。更简单的方式是每次submit时用random.random()和DROP_RATE比较但这样短时间内容易多抽或少抽。我一般用计数器加随机漂移维护一个浮动间隔例如drop_interval在45到55之间震荡一样能保持长期比例又不会产生尖锐的波谷。抽水率越低短时波动越大建议在矿池后台至少看1小时平均算力不要看10分钟。4.5 现象服务器重启后矿机全都连接不上页面显示代理端口拒绝连接原因十有八九是代理没有随系统启动。如果你用nohup python3 eth_pool_proxy.py 启动重启后进程就没了。还有一些情况下Python崩溃后端口没释放也会让新连接直接被拒。解决务必用3.4节的systemd方案并设置Restartalways。另外在启动服务前先执行ss -lntp | grep 3333看端口是否已被占用如果残留僵尸进程用kill -9 PID清掉再启动。4.6 现象矿池后台显示的份额数量比矿机本地显示少了不止2%原因抽水计数器用了全局变量多台矿机连接时计数器被所有矿工共享导致某个矿工被抽的份额远高于设定值另一个矿工却完全没有被抽。我最初实现时把share_count定义成了class变量而不是实例变量立刻出了这个问题。解决确保抽水计数器和drop_interval是每个ProxyHandler实例自己维护的也就是写在__init__里用self.share_count。同时我还会在转发逻辑里把每个矿工的worker名写入一条JSON日志方便按worker核对真实份额。抽水是比例抽不是全局抽这一点必须严格。5. 进阶日志监控、算力审计与API化管理代理跑通后你要面对的不只是“能连”而是“可运营”。我习惯在route_miner_message里对每一次mining.submit追加一行结构化日志输出当前worker名、份额计数、是否被抽、时间戳。日志格式用JSON后续可以扔给ELK或Logstash不用改代码就能接监控面板。import time log_line { timestamp: int(time.time()), worker: worker_name, share_count: self.share_count, dropped: True, wallet: POOL_WALLET } print(json.dumps(log_line), flushTrue)这一步能让算力审计变得极简单把矿工本地算力减去矿池后台算力再除以矿工本地算力结果应该稳定等于你设定的DROP_RATE。如果偏差超过0.5%多半是抽水逻辑有bug或者有矿机连接不稳定导致提交重复。进阶的话可以再加一个HTTP API。Python的asyncio不依赖外部库就能实现一个极简的TCP HTTP服务但更省事是装aiohttp然后用一个协程返回JSON。接口路径只有两个/status返回当前活跃连接数、累计份额、被抽份额/config返回当前抽水率。这样你自己的前端面板就可以实时展示中转节点状态同时也可以拿给矿工看证明你没有多抽。注意这个API不要监听公网至少绑在127.0.0.1用nginx反代加个密钥否则别人访问你的接口就能看到抽水配置。最后验证抽水效果时我不建议一上来就把DROP_RATE设成2%。先设成0跑一小时记录矿池后台显示的算力再改成1%跑一小时看算力是否下降了1%确认无误后再调到2%。这套流程能帮你分离“网络抖动”和“抽水误差”。从那以后我每次部署中转节点都强制先跑一遍0%和1%的对比测试再考虑正式抽水。抽水是用户之间约定的服务费模型不是偷算力的黑匣子留好日志、做好对账节点才能长期稳定跑下去。希望帮到你。本文还有配套的精品资源点击获取