tron-节点-witness加载过程
简述witness 即在tron链中就是产块节点的代名词,一般称为SR。一般节点不产块,要配置成witness,需要启动时指定私钥,并使用--witness或-w指定成为产块节点。
witness 加载过程有两种加载方式:
参数或配置文件
指定localwitness启动
参数或配置文件通过参数指定为witness节点,但是私钥建议写在配置文件中,否则ps查看一下进程就能看到启动参数,就全暴露了,但是如果有人能上机器,也能查看配置文件。
1java -jar FullNode.jar --witness -p xxxxxxxxxxxxxxxxxx
输入上面的命令后,节点就会以SR类型启动,具体是如何加载的,调用栈如下:
1234567FullNode.main()\--Args.setParam(args, Constant.TESTNET_CONF); //381 \--PARAMETER.privateKey //优先加载 参数 \--Constant.LOCAL_WITNESS & ...
tron 接收交易和广播交易
前言分析tron是如何接收到交易,并在接收到交易后,后续是如何处理的,交易处理细节可以看看:tron 交易处理--交易执行逻辑
接收交易节点使用netty进行P2P连接,主要使用到的类:
TransactionsMsgHandler: netty Handler处理器
TronNetService: 消息分发
AdvService: 消息广播
FetchInvDataMsgHandler: 消息拉取
交易处理调用栈:
123TronNetHandler.channelRead0 接收消息\--TronNetService.onMessage 分发消息 \--transactionsMsgHandler.processMessage; 具体业务处理
TronNetService.onMessage 分发消息1234567891011121314151617181920212223242526272829303132333435363738394041protected void onMessage(PeerConnection peer, TronMessage msg) ...
tron-网络模型-AdvService广播服务
AdvService 作用AdvService 负责将数据广播到tron网络当中。基础框架是netty,在此之上开发AdvService对业务进行了封装。
数据包括:
交易
区块
需要注意的是,tron的AdvService的这套广播逻辑,不是单向广播,而是双向互动。啥意思,就是说,一般理解,一条数据广播出去后,就广播到对方节上了。但是tron的广播不是这样,而是先广播一个交易ID到目录节点上,目标节点收到ID后,再发一条请求接取的网络请求,把数据接回去!!!!是不是有点反直觉!!!
AdvService 主要成员invToFetch:invToSpread: 待广播的数据:交易、区块invToFetchCache:
主要方法consumerInvToSpread: 处理发送队列consumerInvToFetch: 处理拉取队列broadcast: 广播
处理流程
broadcast: 构建广播消息体:只包含ID
将数据添加入trxCache/blockCache
封装item
保存待发送消息: invToSpread.put(item)
consumerInvToSpre ...
tron-数据库设计1-接口和内存数据库状态
数据库设计tron的数据库设计是在基于leveldb的基础上抽像自己的相关业务,设计出基于自己的业务数据操作类。有两大块分别是:
内存数据库
持久化数据库
从两个角度进行梳理:
代码设计
业务应用
代码结构
代码结构设计
接口关系、主要功能方面着手了解。
业务使用
generateBlock
pushBlock
pushTransaction
switchFork
一、ITronChainBase 存储操作接口数据库相关的接口比较多,有些关系结构看起来功能相似,反而不容易区分出差异。下面按照功能职责划分。
作用:提供基础数据库基础操作方法。
ITronChainBase: 顶层接口,提供如:put、get、delete等相关操作,包含两个抽象类。
TronStoreWithRevoking: 抽象类,提供构造器中包含初始化方法。各个Store的初始化从这里开始,包含36个Store,如:a. AccountStoreb. BlockStorec. BlockIndexStore
TronDatabase:抽象类,提供的方法大部分为抽像方法,这样的话,实现类可以根据 ...
tron 参与度算法模拟
简述这个算法是在分布式场景下,计算不同节点之前的参与度,也就是有多少节点还存活,并参与到正常的业务处理当中。
为什么需要: 参与度?大白话就是有什么用,不用行不行?在中心化的应用当中,网络的数据处理只需要提交易中心节点处理即可。如下一个订单、注册一个用户。在区块链场景下,所有节点之前都是独立的个体,谁也没有比较权威,在完成一个业务的处理,需要多个节点的认可才可能完成。用不用需要看是使用的哪一种共识协议。如果是POW完全不用考虑,如果是DPOS这种就需要。在分布式环境下,一件事需要处理成功,需要有一定数量的可信节点来证明!、证明!、证明!,否则这件事就不可能被认为是一件可信的事情,比如,有一个节点给自己的账户转了1000万,并生产了一个区块记账,那这个区块必须得到网络中半数以上的验证者认可,那这个区块就是可信的。如果不需要的话,自己可以随意改代码给做对自己有利的事,那这个网络就没有人会信任,所以需要有一定的节点成为:验证者。
验证者那就选出一批验证者来干活。问题是,网络是分布式的,机器、网络节点有可能会故障挂掉,如何确保挂掉一部分验证者后,网络还能继续工作。那就需要保证有一批最小的可信验 ...
tron-资源模型-能量Bandwidth
资源模型tron有两种资源:
带宽 Bandwidth
固定免费额度
质押获得
能量 Energy
固定免费额度
质押获得
资源模型指什么,指tron链当中,每个账户account都拥有的除了代币之外的资源。这个资源是在执行交易或智能合约时,进行消耗的资源,大白话就是交易都有手续费,这个资源就相当于免费给你的资源,可以用来抵销转账的手续费,每个账户免费额度有限。
tron链中主要有两种资源模型:带宽和能量。这个模型对标以太坊的 gas 费。
什么意思呢?举个例子,比如玩游戏,游戏人物都有蓝条,这个蓝条使有技术就会耗蓝,这个蓝量会在一定时间内自动恢复。这个能量和带完是一样的道理。
会在24小时恢复tron链当中,每个账户都会拥有一定的免费资源额度,如果用完免费额度,就用账户中的代币抵扣,这个免费额度会在24小时内逐步恢复到一个初始值。
免费的能量有多少?
免费带宽是个固定值:1500。
质押能量有多少?
这个值是个动态值,跟参与这个游戏的人数有关。这里有一个概念,就是全网总能上限,就是全网最大的一个带宽上限。每个人都能从里面分到一点资源,当作一种福利看。
能分到多少,就要 ...
tron ECC使用及项目中的应用
简述ECC(Elliptic Curves Cryptography,椭圆曲线密码编码学)是一种公开密钥算法。基于椭圆曲线数学的公开密钥加密算法,其本质是利用离散对数问题实现加密。ECC的主要优势,是在使用更小的密钥的同时,提供更快的性能和更高等级的安全。网上的理论大都讲的非常透彻,我也是看了很多,但是实际能力有限,对数论层面的只停留在浅薄的理解上,不敢乱讲。但是可以简单的说明其原理。
还有一点,加密算法包括RSA和ECC并不是不可以被破解,只是以当下现代计算机的计算性能算起来比较费劲,理论上破解ECC需要最少250万年,其破解的代价很高,以此来达到不可破解目的。用量子计算?不说现在有量子技术可不可么,假设量子计算可是可行的,那为什么不升级到量子加密?
ECC: 基于椭圆曲线和离散对数其原理是数论理论中的单向运算函数,这种函数有一个特点:正方向计算容易,反方向计算却十分困难。啥意思?就是计算:
1234 * 4567 = ?
计算这个简单,结果是:5635678。那么,返过来计算:
5635678 = x * y
这样就不好计算了,而且结果有很多种有可能是:
5635678 ...
tron checkpoint数据还原点
前言TRON 的数据还原点checkpoint指的是数据在某一刻建立的一个快照的备份,给内存快照(snapshot)生成一个临时持久化存储。
作用保存数据在内存中的状态到碰盘,用于服务异常数据异常恢复。checkpoint 是将某一时刻在内存在还没有写入到磁盘中的数据,临时写入到磁盘当中,当处理成功后删除本次的checkpoint,待下一次刷盘时,重新创建checkpoint,重复这个过程。
在此之前需要对TRON的内存快照机制有一定的了解。
刷盘机制TRON中的刷盘和很多别的应用的刷盘一样,都是将内存中的数据刷入到磁盘当中。也就是说:TRON对数据的写入是先内存,后磁盘。如果数据在内存当中就会存在一个问题,如果服务进程挂了,那内存中的数据就会丢失。举个例子:比如:
A 给 B 转10块钱,这笔交易需要等待刷盘时机触发,才会写入到内存当中此时,服务挂了,这个数据并没写入到磁盘中,那么这笔交易就丢失了。
为了解决这一问题的,使用 checkpoint 机制。
先看一下内存中的数据结构图,每一次对区块操作,都会创建一个对应区块的checkpoint。SnapshotRoot是对leve ...
tron 编码 二进制、base58check、Hex
编码在TRON中使用到的其中二种编码:
base58check
hex
byte
为什么说这三种编码,主要是这三种比较常用。首先用到最多的就是地方就是基于byte[]衍生的各种编码场景如:
私钥
protobuf
leveldb存储
都是先基于byte数据来的,其它区块链当中也有大量使用byte。
byte使用场景:
数据存储
网络传输
这个比较在常用,在tron链中,越是底层的数据存储越是需要二进制,如私钥、数据存储等,就是byte[]这种格式。使用protobuf序列化也是byte[],leveldb 的存储也是基于byte[]。可以理解为,最重要和核心的数据形式。但是byte也有一个问题,就是表现形式上,太长了,不利于人类的阅读体验。数据之间需要进行转换才能使用,首先,数据存储到leveldb中,是只能存储二进制数据,也就是在源头上,数据就必须是二进制形式存在的,如果要使用转换数据是必然的行为。当然你说我就要二进制,就不嫌麻烦,整套系统都用二进制操作,也不是不可以,效率是少了一步转换肯定是可以,但是内存上有没有那么大的空间。二是我调试时,看二进制没问题,完全不在话下, ...