Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序，Get更优阅读体验！
立即前往
文档建议反馈控制台
首页
学习
活动
专区
圈层
工具
MCP广场
文章/答案/技术大牛
发布
首页
学习
活动
专区
圈层
工具
MCP广场
返回腾讯云官网
社区首页 >专栏 >MySQL 主从复制 1594 报错分析

MySQL 主从复制 1594 报错分析

作者头像
爱可生开源社区
发布于 2025-03-28 05:00:12
发布于 2025-03-28 05:00:12
9400
代码可运行
举报
文章被收录于专栏：爱可生开源社区爱可生开源社区
运行总次数：0
代码可运行
关联问题
换一批
作者：陈伟，爱可生 DBA 团队成员，负责 MySQL 日常维护及故障处理。

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文约 2600 字，预计阅读需要 8 分钟。

1. 故障背景

客户反馈 MySQL 主从复制出现故障，检查后发现 SQL 线程停止写入报错 1594，但 IO 线程仍能正常拉取日志。

在从库执行 reset slave 命令并重建复制后，主从复制恢复正常。下面分析此次报错的详细原因。

为了给予客户更全面的的解答，本次采取全面排查的方式，逐个分析所有可能导致该故障的因素，找出最有可能引发此次故障的原因，以给客户提供一个准确的解释。

以下是本次故障分析的思路。

2. 故障分析

MySQL 版本：5.7.26，GTID 已启用。

2.1 查看从库报错信息

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> show slavestatus\G
*************************** 1.row ***************************
               Slave_IO_State: Waiting formasterto send event
                  Master_Host: xx.xx.xx.xx
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.xxxxxx
          Read_Master_Log_Pos: xxxxxx
               Relay_Log_File: mysql-relay.xxxxxx
                Relay_Log_Pos: 243865
        Relay_Master_Log_File: mysql-bin.xxxxxx
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay logreadfailure: Could notparse relay logevent entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay logis corrupted (you can check this by running 'mysqlbinlog'on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want tocheck the master's binary log or slave's relay log, you will be able to know their namesby issuing 'SHOW SLAVE STATUS'on this slave.
                 Skip_Counter: 0

根据 show slave status\G 得到主从报错的信息，我们可以很明确，读取 relay log 失败，无法解析中继日志中的事务。

2.2 查看从库错误日志

查看从库对应时间点的错误日志。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
2024-12-29T00:22:19.824988+08:00 241186 [ERROR] Error in Log_event::read_log_event(): 'Event crc check failed! Most likely there is event corruption.', data_len: 8060, event_type: 31
2024-12-29T00:22:19.825014+08:00 241186 [ERROR] Error reading relay log event for channel '': slave SQL thread aborted because of I/O error
2024-12-29T00:22:19.825027+08:00 241186 [ERROR] Slave SQL for channel '': Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 1594
2024-12-29T00:22:21.146920+08:00 241186 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.053394' position 264587564.

根据错误日志中的报错信息，我们可以得到一些关键信息如下:

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
2024-12-29T00:22:19.824988+08:00 241186 [ERROR] Error in Log_event::read_log_event(): 'Event crc check failed! Most likely there is event corruption.', data_len: 8060, event_type: 31
# 可以发现有 Event crc check failed 信息输出，这个错误通常表示日志事件的 CRC 校验失败，可能是由于事件的数据损坏或日志文件不完整。
# 当从库读取中继日志时，如果发生 CRC 校验错误，是可能导致从库的 SQL 线程中止，并报错 Relay Log Read Failure
2024-12-29T00:22:19.825027+08:00 241186 [ERROR] Slave SQL for channel '': Relay log read failure: Could not parse relay log event entry......... Error_code: 1594

根据错误日志得到的信息，可以发现存在日志事件的 CRC 校验失败。CRC 校验失败通常意味着数据在传输或存储过程中发生了损坏，可能的原因包括磁盘故障、网络问题、MySQL 服务异常关闭或者主库的 binlog 文件损坏或者从库的 relay log 损坏，从而导致无法解析中继日志中的事务。

2.3 进一步排查可能中断的原因

首先检查一下对应时间点的系统日志，没有异常信息输出，排除磁盘故障，也未发现报错时段的 MySQL OOM 信息。

排查是否是事务过大，比如事务超过 max_allowed_packet 限制，发生的分片写入错误。

根据中断时的最后一个 gtid 信息可得在写 019edbbe-8c87-11ee-a06d-005056943f0f:625715013 时 SQL 线程中断。计算该 gtid 事务的大小，根据计算得出该事务大小为 20M，本次故障排除事务过大导致。

最后检查了主库故障时间点的 MySQL 服务状态以及对应时间主库的 binlog 文件，并没有发现任何异常，同时查看故障时间点的网络监控，也是正常的。

到这基本很明确是 relay log 这边出现了问题，从而导致无法解析中继日志中的事务。由于客户环境未能保留报错时的 relay log ，所以只能去通过自己的环境去复现客户故障，并与客户故障环境已采集的信息作比对。

2.4 本地环境复现

查看当前环境主从状态。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> show slavestatus\G
*************************** 1.row ***************************
               Slave_IO_State: Waiting formasterto send event
                  Master_Host: 10.186.63.44
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 3527783
               Relay_Log_File: mysql-relay.000003
                Relay_Log_Pos: 10303
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:

手动关闭 SQL 线程。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> STOP SLAVE SQL_THREAD;
Query OK, 0 rows affected (0.00 sec)

查看当前复制状态。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> show slavestatus\G
*************************** 1.row ***************************
               Slave_IO_State: Waiting formasterto send event
                  Master_Host: 10.186.63.44
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 3510430
               Relay_Log_File: mysql-relay.000004
                Relay_Log_Pos: 12695
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: No

再次查看复制状态。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.186.63.44
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 3560144
               Relay_Log_File: mysql-relay.000007
                Relay_Log_Pos: 4675
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: No

此刻观察到环境信息与客户环境一致，SQL 线程停止写入，IO 线程正常拉取日志。

模拟 SQL 线程故障：使用 hexedit[1] 编辑 relay log 文件。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
hexedit mysql-relay.000007

开启 SQL 线程查看复制状态。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysql> START SLAVE SQL_THREAD;
Query OK, 0 rows affected (0.02 sec)

mysql> showslavestatus\G
*************************** 1.row ***************************
               Slave_IO_State: Waiting formasterto send event
                  Master_Host: 10.186.63.44
                  Master_User: universe_op
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 32050487
               Relay_Log_File: mysql-relay.000007
                Relay_Log_Pos: 243865
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay logreadfailure: Could notparse relay logevent entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay logis corrupted (you can check this by running 'mysqlbinlog'on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want tocheck the master's binary log or slave's relay log, you will be able to know their namesby issuing 'SHOW SLAVE STATUS'on this slave.
                 Skip_Counter: 0

查看 MySQL 报错信息。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
024-12-31T09:34:36.385535+08:00 1448 [ERROR] Error in Log_event::read_log_event(): 'Event crc check failed! Most likely there is event corruption.', data_len: 80, event_type: 31
2024-12-31T09:34:36.385593+08:00 1448 [ERROR] Error reading relay log event for channel '': slave SQL thread aborted because of I/O error
2024-12-31T09:34:36.385608+08:00 1448 [ERROR] Slave SQL for channel '': Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 1594
2024-12-31T09:34:36.386764+08:00 1448 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000001' position 3795113.

至此，通过上面的排除法，以及通过比对本地环境复现的报错信息，可明显判断导致 1594 报错的原因是：在传输或者写入 relay log 的过程中，中继文件意外发生了损坏，从而导致 SQL 线程无法拉取中继日志。

2.5 继续解析 relay log

下面我们解析一下 relay log ，看一下有哪些报错的提示信息输出，并进行总结。

首先先解析 relay log 查看报错，可以正常解析，看不出来什么异常。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
# at 243865
#241231  1:12:35 server id 675216691  end_log_pos 3795178 CRC32 0x886c766d      GTID    last_committed=8108     sequence_number=8109    rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ee2fddba-c6c7-11ef-8e2a-02000aba3f2c:8109'/*!*/;
# at 243930
#241231  1:12:35 server id 675216691  end_log_pos 3795254 CRC32 0x31082f91      Query   thread_id=71    exec_time=0     error_code=0
SET TIMESTAMP=1735578755/*!*/;
BEGIN;44006
#241231  1:12:35 server id 675216691  end_log_pos 3795412 CRC32 0xd1baa47b      Rows_query
# /*ustats-10-186-63-44*/update universe.u_delay set real_timestamp=now(), logic_timestamp = logic_timestamp + 1 where source = 'ustats'
# at 244164
#241231  1:12:35 server id 675216691  end_log_pos 3795471 CRC32 0x9b859b01      Table_map: `universe`.`u_delay` mapped to number 211
# at 244223
#241231  1:12:35 server id 675216691  end_log_pos 3795551 CRC32 0x69696969      Update_rows: table id 211 flags: STMT_END_F
BINLOG '/T4ongAAANTpOQCAAIYvKnVzdGF0cy0xMC0xODYtNjMtNDQqL3VwZGF0ZSB1bml2ZXJz
ZS51X2RlbGF5IHNldCByZWFsX3RpbWVzdGFtcD1ub3coKSwgbG9naWNfdGltZXN0YW1wID0gbG9n
aWNfdGltZXN0YW1wICsgMSB3aGVyZSBzb3VyY2UgPSAndXN0YXRzJ3ukutE=
g9RyZxMz/T4oOwAAAA/qOQAAANMAAAAAAAEACHVuaXZlcnNlAAd1X2RlbGF5AAMPEggD+AIABgGb
hZs=Zx8z/T4oUAAAAF/qOQAAANMAAAAAAAEAAgAD///4BgB1c3RhdHOZtT4TIkQfAAAAAAAA+AYA
dXN0YXRzmbU+aWlpaWlpaWlpaWlpaWk=
'/*!*/;ATE `universe`.`u_delay`
### WHERE
###   @1='ustats' /* VARSTRING(760) meta=760 nullable=0 is_null=0 */
###   @2='2024-12-31 01:12:34' /* DATETIME(0) meta=0 nullable=1 is_null=0 */
###   @3=8004 /* LONGINT meta=0 nullable=1 is_null=0 */
### SET1='ustats' /* VARSTRING(760) meta=760 nullable=0 is_null=0 */
###   @2='2024-12-31 06:37:41' /* DATETIME(0) meta=0 nullable=1 is_null=0 */
###   @3=7595718147998050665 /* LONGINT meta=0 nullable=1 is_null=0 */
# at 244303
#241230 17:35:37 server id 675216691  end_log_pos 3795582 CRC32 0x48e0358c      Xid = 85886
COMMIT/*!*/;

由于可以正常解析，那么我们就通过 MySQL 自带的 mysqlbinlog 来验证 relay log 中故障时间点前后事件的 CRC，看看有没有什么异常信息输出。

命令及输入如下：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
mysqlbinlog --verify-binlog-checksum mysql-relay.000007

查看输出内容：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
# at 243865
#241231  1:12:35 server id 675216691  end_log_pos 3795178 CRC32 0x886c766d      GTID    last_committed=8108     sequence_number=8109    rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ee2fddba-c6c7-11ef-8e2a-02000aba3f2c:8109'/*!*/;
# at 243930
#241231  1:12:35 server id 675216691  end_log_pos 3795254 CRC32 0x31082f91      Query   thread_id=71    exec_time=0     error_code=0
SET TIMESTAMP=1735578755/*!*/;
BEGIN
/*!*/;
# at 244006
# at 244164
#241231  1:12:35 server id 675216691  end_log_pos 3795471 CRC32 0x9b859b01      Table_map: `universe`.`u_delay` mapped to number 211
ERROR: Error in Log_event::read_log_event(): 'Event crc check failed! Most likely there is event corruption.', data_len: 80, event_type: 31
ERROR: Could not read entry at offset 244223: Error inlog format or read error.
WARNING: The range of printed events ends with a row event or a table map event that does not have the STMT_END_F flag set. This might be because the last statement was not fully written to the log, or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement. The event(s) from the partial statement have not been written to output.

发现有 CRC 报错输出，relay log 读取报错原因是 最后一个事务未完整写入。

3. 总结

首先，在进行 MySQL 故障处理时，应先尽量保留下必要的信息以方便后续排查具体的原因，再去处理故障、恢复业务。其次，针对 1594 主从故障，一般情况有以下几个原因导致，我们可以针对可能导致的原因并结合数据库的错误日志进行进一步排查和修复。

  • 中继日志文件损坏：磁盘故障、非正常关机导致文件损坏。
  • 磁盘空间不足：从库无法写入新的事件到中继日志。
  • 主库日志丢失：主库清理了未同步的二进制日志，导致从库请求的日志位置失效。
  • 权限或路径错误：MySQL 进程无权访问中继日志文件，或路径配置错误。

参考资料

[1]hexedit: https://hexed.it/

本文关键字：#MySQL# #主从复制# #1594#

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2025-03-27，如有侵权请联系 cloudcommunity@tencent.com 删除
事务
线程
mysql
日志
事件

本文分享自 爱可生开源社区 微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ，欢迎热爱写作的你一起参与！

事务
线程
mysql
日志
事件
评论
登录后参与评论
暂无评论
登录 后参与评论
推荐阅读
编辑精选文章
换一批
万字详解高可用架构设计
2193
Go 开发者必备：Protocol Buffers 入门指南
1251
10分钟带你彻底搞懂分布式链路跟踪
786
基于Ordinals在比特币L1网络实现EVM图灵完备智能合约支持——BxE协议
网络协议以太坊智能合约比特币
区块链技术自诞生以来，为金融、供应链、数字身份等领域带来了变革性的创新。然而，作为第一个成功应用区块链技术的比特币，存在着一些局限性，如较低的交易吞吐量、较高的能源消耗以及有限的脚本功能。这使得比特币在支持复杂应用和智能合约方面显得力不从心。
深蓝studyzy
2024/04/17
2160
基于Ordinals在比特币L1网络实现EVM图灵完备智能合约支持——BxE协议
BTA | 杨德升：掌握这些技术点，现在就能做一个Dapp！
其他
区块链大本营出品 整理 | Aholiab 3月30日~3月31日，由CSDN、火星财经主办，中关村区块链产业联盟、柏链道捷、区块链大本营、TokenSky联合主办的区块链技术及应用峰会(BTA)·中国，在北京喜来登长城饭店盛大举行。 作为时下最热门的行业话题，区块链以其颠覆性的技术理念，正在对各个行业施以影响，吸引了全球技术圈、投资者、创业者的关注。为了深入理解区块链及其背后的技术本质，本次大会邀请了80+区块链技术领导人物、100+区块链投资商业大咖，就区块链的发展趋势进行探讨，让人们有机会全面了解这一
区块链大本营
2018/05/10
1.5K0
本体技术视点 | 智能合约安全与漏洞分析（二）
区块链网络安全安全
智能合约安全问题一直是区块链技术体系中探讨得比较多的话题之一。无论是以以太坊 EVM 虚拟机为代表的智能合约体系，还是以 EOS WASM 虚拟机为代表的智能合约体系，都或多或少地暴露过不同类型的智能合约漏洞。这些漏洞不仅使得项目方和用户损失惨重，而且也让用户对区块链的安全性产生了质疑。
本体Ontology
2019/12/05
4950
本体技术视点 | 智能合约安全与漏洞分析（二）
主网三周年特辑 | 全面兼容以太坊生态的Ontology EVM亮相
网站api区块链
早在今年伊始，本体技术团队开始了本体版本 EVM 的研发。在已有的三种多虚拟机（NeoVM、Native 和 Wasm）的基础上，增加最具有广泛适用性的 EVM（以太坊虚拟机）。目标是尽可能保持本体和以太坊平台的无缝衔接，带来对开发者与用户高度友好的体验。
本体Ontology
2021/07/12
5790
主网三周年特辑 | 全面兼容以太坊生态的Ontology EVM亮相
区块链学堂——区块链词汇手册
区块链
【区块链】：Blockchain，分布式存储、加密算法、共识机制、P2P传输等计算机技术结合的新型应用模式。 【区块】：Block，用于记录区块链系统中数据的存储。 【链】：chain，区块头中通过引用哈希值链接。 【区块链服务】：BAAS，blockchain as a service，区块链即服务。 【分布式】：Decentralized，不依赖中心服务器，分布的计算机资源进行计算处理的模式。 【共识机制】：consensus，区块链中事务达成的分布式共识算法。 【P2P传输】：peer-to-pe
企鹅号小编
2018/01/24
17.5K0
区块链学堂——区块链词汇手册
Ethereum 核心技术解读
区块链存储ethereum网络智能合约
比特币作为一种去中心化的数字货币，是极其成功的，但受限于比特币脚本（非图灵完备，只能处理一些简单的逻辑），并不能处理很复杂的业务。而Ethereum引入了智能合约，使去中心化的概念能够应用于更丰富的应用场景，因此也被称为区块链 2.0。本文将对以太坊核心技术进行解读，如有错漏，欢迎交流指正。
pseudoyu
2023/04/11
7350
Ethereum 核心技术解读
比原链设计思考: 扩展性UTXO模型
数据结构区块链比特币
用户模型是比原链在最初就需要确定的重要数据结构， 团队的选择还是聚焦在两种典型的模型系统中，Account模型和UTXO模型，和其他大多数区块链设计一样， 选择了模型就决定了协议层的重要实现，两种模型各有利弊，不同区块链针对想聚焦的场景自身会有判断。
比原链Bytom
2018/08/27
4310
比原链设计思考: 扩展性UTXO模型
USDT PHP开发包OmniTool简介
比特币rpc
OmniTool开发包适用于为PHP应用快速增加对Omni Layer/USDT数字资产的支持能力，即支持使用自有Omni Layer节点的应用场景，也支持基于第三方API服务和离线裸交易的轻量级部署场景。下载地址：omni/usdt php开发包 。
用户1408045
2019/06/11
2.3K0
USDT PHP开发包OmniTool简介
码农看享云链多资产token技术的原理与应用
区块链数字货币
企业为什么需要多资产token？ 区块链上token是安全、可流通的数字权益证明，它可以代表任何的权益，比如使用权、股权等等。现实生活中的各种权益证明，不管是所有权还是著作权、债券还是代金券、货币还是票据的都可以数字化、通证化，并接入区块链平台进行快速而又安全的交易。 企业和个人在区块链上发行token资产已是当下区块链时代的时髦行为，因其可极大地降低交易成本。而一个运营能力专业，技术氛围良好，用户数量大，用途广泛，高效、安全与易用的商用区块链平台，才能保证资产切实有效的发行。 享云链率先原生支持单账户多币种，并支持通过合约发行隐私Token 目前像以太坊这样的公链，新增资产的发行、交易、转账都只能在合约中进行。对开发人员和资深用户来说，原生token与合约发行的token交易操作截然不同。虽然以太坊提出ERC-20等标准协议来支持用户发行资产，但用户仍需通过调用合约方式来进行转账操作，这种方式影响了转账效率（需要执行合约交易，拉起虚拟机），也引入了风险（非标准合约发行）。
互链脉搏
2020/01/10
6490
EOS是什么_电脑EOS是什么
数字货币网站区块链
EOS是什么 EOS是Enterprise Operation System的缩写，它是商用分布式应用设计的一款区块链操作系统。EOS是引入的一种新的区块链架构EOSIO，用于实现分布式应用的性能扩展。EOS并不像比特币和以太坊那样是货币，而是基于EOSIO软件项目之上发布的代币，被称为区块链3.0。
全栈程序员站长
2022/08/04
2.9K0
EKT多链技术谈 | EKT如何实现区块链世界的“用户共享”
打包区块链比特币数字货币
在区块链系统中，用户体系是一个非常非常重要的部分。为什么这么说呢？因为它直接决定了一个区块链项目上用户的资产安全。接下来我会从技术角度详解——EKT的用户体系为何安全？为何能够向链上企业实现用户的共享？
风中凌乱的靓仔
2019/03/22
8420
EKT多链技术谈 | EKT如何实现区块链世界的“用户共享”
区块链入门总结区块链
区块链比特币编程算法二叉树存储
新交易创建 -> 交易广播网络 -> 交易验证 -> 验证结果通过网络广播 -> 交易写账本
若与
2018/09/29
53K1
区块链入门总结区块链
权威指南 | 从入门到进阶，专家教你上手公链开发
其他
了解公链的第一步，是阅读白皮书。白皮书是公链的灵魂，也是驱动公链开发的指导性文档，通过阅读白皮书，可以找到一条区块链开发的完整愿景和路线图。
区块链大本营
2018/12/20
1.5K0
权威指南 | 从入门到进阶，专家教你上手公链开发
substrate 合约模块简要剖析(一)
区块链
本文主要介绍 substrate 合约模块的实现逻辑，srml/contracts 提供了部署和执行 WASM 智能合约的功能。作为一个模块化的区块链框架，不管是未来的波卡平行链还是基于 substrate 拥有独立共识的链，比如 ChainX, 只要引入其合约模块，就具备了合约功能，可以成为一个智能合约平台。ChainX 目前就计划引入合约功能，对区块链智能合约开发者提供支持, 欢迎有兴趣的同学持续关注。
用户1558438
2019/09/27
1K0
substrate 合约模块简要剖析(一)
Omni Layer USDT区块链开发包简介【OmniTool.Java】
rpcapi比特币区块链数字货币
OmniTool.Java开发包适用于为Java应用快速增加对Omni/USDT数字资产的支持能力，即支持使用自有Omni节点的应用场景，也支持基于第三方API服务和离线裸交易的轻量级部署场景。官方下载地址：http://sc.hubwiz.com/codebag/omni-java-lib/。
用户1408045
2019/12/01
1.9K0
社区观点 | 理解比原链MOV链上交换协议
区块链
从Bitshare，Stellar到以太坊上的Etherdelta，Bancor，0x协议，去中心化交换协议也经过了好几代发展和很多模式的探索，每一代都通过前面的协议的痛点来进行改进和深化，
比原链Bytom
2020/01/02
4370
PalletOne调色板跨链的BTC实现
比特币数字货币编程算法打包
之前已经讲到了PalletOne调色板跨链以太坊ETH和ERC20的技术原理，接下来我们来讲解PalletOne跨链比特币BTC的技术原理。
深蓝studyzy
2022/06/16
7220
PalletOne调色板跨链的BTC实现
Bytom设计结构解读
数据结构sql分布式
设计Bytom 数据结构，组合了许多技术点，如 patricia tree，utxo， bvm， account model，protobuf，sql，memcache 等。本文会对一些技术点做以下两点分析。
比原链Bytom
2018/07/26
3620
Bytom设计结构解读
PalletOne调色板跨链的ETH提币实现
区块链编程算法linux
实现区块链的跨链，最主要的诉求就是Token的转移，而Token的跨链转移又分为充币和提币2种操作。以PalletOne调色板来说，如果要把ETH跨链到PalletOne上来流转，就是ETH的充币操作，要将PalletOne上的PETH（PalletOne上发行的与ETH1:1等值兑换的Token）跨链回到以太坊，变成ETH，就是ETH的提币操作。
深蓝studyzy
2022/06/16
1.1K0
PalletOne调色板跨链的ETH提币实现
蚂蚁区块链第6课 TEE硬件隐私合约链(含标准合约链)的框架和功能概述
区块链
本文介绍蚂蚁区块链的TEE硬件隐私合约链和标准合约链的框架和功能介绍，说明开发流程。 TEE 硬件隐私合约链是在标准合约链功能基础上采用TEE硬件叠加隐私保护相关功能。
辉哥
2019/04/01
3K0
蚂蚁区块链第6课 TEE硬件隐私合约链(含标准合约链)的框架和功能概述
推荐阅读
编辑精选文章
万字详解高可用架构设计Go 开发者必备：Protocol Buffers 入门指南10分钟带你彻底搞懂分布式链路跟踪
相关讨论
cloud 集成 zipkin 进行调用链追踪 服务发现正常采样1.0 显示0% ？TRTC在小度在家1C畅享版上本地预览黑屏及本地视频流无法推送？用 sql server 怎么完成下面的问题 试半天试不出来？
相关课程
AI代码助手快速上手训练营腾讯云开发玩转小程序实战训练营大数据
基于Ordinals在比特币L1网络实现EVM图灵完备智能合约支持——BxE协议
2160
BTA | 杨德升：掌握这些技术点，现在就能做一个Dapp！
1.5K0
本体技术视点 | 智能合约安全与漏洞分析（二）
4950
主网三周年特辑 | 全面兼容以太坊生态的Ontology EVM亮相
5790
区块链学堂——区块链词汇手册
17.5K0
Ethereum 核心技术解读
7350
比原链设计思考: 扩展性UTXO模型
4310
USDT PHP开发包OmniTool简介
2.3K0
码农看享云链多资产token技术的原理与应用
6490
EOS是什么_电脑EOS是什么
2.9K0
EKT多链技术谈 | EKT如何实现区块链世界的“用户共享”
8420
区块链入门总结区块链
53K1
权威指南 | 从入门到进阶，专家教你上手公链开发
1.5K0
substrate 合约模块简要剖析(一)
1K0
Omni Layer USDT区块链开发包简介【OmniTool.Java】
1.9K0
社区观点 | 理解比原链MOV链上交换协议
4370
PalletOne调色板跨链的BTC实现
7220
Bytom设计结构解读
3620
PalletOne调色板跨链的ETH提币实现
1.1K0
蚂蚁区块链第6课 TEE硬件隐私合约链(含标准合约链)的框架和功能概述
3K0
相关推荐
基于Ordinals在比特币L1网络实现EVM图灵完备智能合约支持——BxE协议
更多 >
前端黑板报0
LV.1
这个人很懒，什么都没有留下～
文章
184
获赞
688
专栏
1
作者相关精选
加入讨论
的问答专区 >
不惑
1产品KOL擅长5个领域
相关课程
一站式学习中心 >
AI代码助手快速上手训练营
1853人在学
腾讯云代码助手
腾讯云开发玩转小程序实战训练营
1546人在学
云开发 CloudBase
大数据
533人在学
大数据
领券

腾讯云开发者

扫码关注腾讯云开发者

扫码关注腾讯云开发者

领取腾讯云代金券

热门产品

热门推荐

更多推荐

Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有 

深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

腾讯云计算（北京）有限责任公司 京ICP证150476号 |  京ICP备11018762号 | 京公网安备号11010802020287

问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档

Copyright © 2013 - 2025 Tencent Cloud.

All Rights Reserved. 腾讯云 版权所有

登录 后参与评论
2
本文部分代码块支持一键运行，欢迎体验
本文部分代码块支持一键运行，欢迎体验