2022-05-10-aptos在开发网的部署和更新 Block Chain Aptos aptos在开发网的部署和更新 该部署方案针对的是开发网devnet。 硬件要求： For running a production grade FullNode: CPU: 4 cores (Intel Xeon Skylake or newer). Memory: 8GiB RAM. For running the FullNode for development or testing: CPU: 2 cores. Memory: 4GiB RAM. 存储要求： Aptos 存储的数据量取决于区块链的账本历史（长度）和链上状态（例如账户）的数量。 这可能受到许多因素的影响，包括：区块链的年龄、平均交易率和账本修剪器的配置。 生成密钥和公钥Peer地址 为了固定身份，可以预先获得一批密钥和公钥Peer地址，源代码方式和Docker方式皆可。 # 源代码 # 生成密钥文件 cargo run -p aptos-operational-tool -- generate-key --encoding hex --key-type x25519 --key-file private-key.txt # 生成公钥地址 cargo run -p aptos-operational-tool -- extract-peer-from-file --encoding hex --key-file private-key.txt --output-file peer-info.yaml # docker docker run --rm aptoslab/tools:devnet sh -c "echo '开始生成私钥...' && aptos-operational-tool generate-key --encoding hex --key-type x25519 --key-file /root/private-key.txt && echo '\n\n开始生成公钥和 Peer ID...' && aptos-operational-tool extract-peer-from-file --encoding hex --key-file /root/private-key.txt --output-file /root/peer-info.yaml && echo '\n\n您的私钥：' && cat /root/private-key.txt && echo '\n\n您的公钥和 Peer ID 信息如下：' && cat /root/peer-info.yaml" 如何使用固定身份 修改 public_full_node.yaml 的 full_node_networks.identity 字段，有两种类型，from_config 和 from_storage。在测试初期使用前一种方法，后期可能要转移到 from_storage 方案。 ...

2022-05-07-aptos 基础概念 Block Chain [[Aptos]] AptOS 相关 网络拓扑 APTOS 网络内有三类节点，两种网络。 三类节点： validator：部分地方记做 validator node。存在独立验证网络内，用于链上共识，负责出块 validator full node：存在公共网络内，和 validator 直接连接，获取出块信息，并进行验证 public full nodes：存在公共网络内，常见的节点，从 validator full node 同步状态 两种网络： validator network public full node network 以上三类节点，都通过软件 aptos-core 支持。加入到不同网络，或指定自身运行状态，来确认自身属于哪个网络。一般来说，个人用户难以加入到validator network。 常见网络概念明确 devnet：开发网，部分地方简称为测试网，和testnet不一样，一般来说每周五更新 testnet：测试网，一般指的是本地测试网，用于代码开发的调试 mainnet：主网，目前没上线 Aptos Incentivized Testnet：激励测试网，目前关注度很高，预计5.13开启报名。该网络分四个阶段，有token奖励。 相关链接 aptos在开发网的部署和更新 Aptos Lab 网站: https://aptoslabs.com/ Dev Guides: https://aptos.dev/ Twitter: https://twitter.com/aptoslabs Medium: https://medium.com/aptoslabs Logos: https://drive.google.com/drive/folders/1AxkH3wfEGLo1DKJ-1OWxMGA4G_Cy8cnB Github: https://github.com/aptos-labs/aptos-core/ 区块游览器: https://explorer.devnet.aptos.dev/ 开发测试网信息: https://status.devnet.aptos.dev/ 节点测试网站： https://www.nodex.run/aptos_test/ https://node.aptos.zvalid.com/ https://aptos-node.info/

2022-04-29-btt网络相关 Block Chain BTFS btt/btfs 网络相关 btfs 项目是一个带宽/存储类项目，对于网络的需求是很大的，下面会列举几个关于网络的问题。 先明确一些概念： 内网：指的是机房内网 外网：指的是中国广域网，也就是最常接触到的网络 境外网：指的是海外网络 公网映射：指的是在核心路由上的配置，可以实现从外网到内网的访问 btfs 需要公网映射吗？ 问题可以参考 [2022-04-27-btfs 的公网映射](./2022-04-27-btfs 的公网映射)..最新的测试结果显示，节点不需要配置公网映射，可以在链上交互数据，也持有合理的主机得分。 btfs 需要境外网络出口吗？ 推荐要上，官方目前给的三个主网 rpc 都是美国加州的地址，因为国内网络环境复杂，可能存在DNS污染、GFW封锁等原因，心跳信息无法传递，使节点无法正常的运行。（出现此问题后，web面板会显示：网络不稳定，无法连接到 btfs 网络）。下面是这三个 rpc 地址和基础信息。 # https://bttc.trongrid.io/ $ ping bttc.trongrid.io PING bttc-trongrid-134413502.us-east-1.elb.amazonaws.com (3.217.237.146): 56 data bytes Request timeout for icmp_seq 0 ^C --- bttc-trongrid-134413502.us-east-1.elb.amazonaws.com ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss $ curl cip.cc/3.217.237.146 IP : 3.217.237.146 地址 : 美国 美国 数据二 : 美国 | 弗吉尼亚州阿什本Amazon数据中心 数据三 : 美国弗吉尼亚阿什本 | 亚马逊 URL : http://www.cip.cc/3.217.237.146 # https://rpc.bt.io/ $ ping rpc.bt.io PING rpc.bt.io (52.7.235.42): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 ^C --- rpc.bt.io ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss $ curl cip.cc/52.7.235.42 IP : 52.7.235.42 地址 : 美国 弗吉尼亚州 阿什本 运营商 : amazon.com 数据二 : 美国 | 弗吉尼亚州阿什本Amazon数据中心 数据三 : 美国弗吉尼亚阿什本 | 亚马逊 URL : http://www.cip.cc/52.7.235.42 # https://rpc.bittorrentchain.io/ $ ping rpc.bittorrentchain.io PING rpc.bittorrentchain.io (52.7.235.42): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 ^C --- rpc.bittorrentchain.io ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss $ curl cip.cc/52.7.235.42 IP : 52.7.235.42 地址 : 美国 弗吉尼亚州 阿什本 运营商 : amazon.com 数据二 : 美国 | 弗吉尼亚州阿什本Amazon数据中心 数据三 : 美国弗吉尼亚阿什本 | 亚马逊 URL : http://www.cip.cc/52.7.235.42 arp 异常问题 # tail -10 /var/log/syslog Apr 28 19:16:57 nl-5288-V5 kernel: [365687.050754] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.051954] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.052283] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.074320] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.074871] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.139645] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.146649] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.146961] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.147239] neighbour: arp_cache: neighbor table overflow! Apr 28 19:16:57 nl-5288-V5 kernel: [365687.147509] neighbour: arp_cache: neighbor table overflow! arp 是地址解析协定，一般只在内网有效，系统内维护一张 arp 表，对应了ip和mac地址，这样内网的数据传输会很快。在我们的机器内，arp 的数量在 101 个，这是合理的，他包括了 100 个 docker 容器的虚拟地址mac映射和网关的mac映射，按理说不会出现上述问题。这个问题影响范围不好确认。 ...

2022-04-27-btfs 基础 Block Chain BTFS BTFS 基础 架构 btfs 是 BTTC 的一项应用，是一个分布式协议。注意：btfs 和 btt 是两个完全不同的概念，需要分清楚，btfs 是一项应用，btt 是代币，在 btfs 内可以通过存储/空投获得 btt 收益。除此之外，btt 在很多其他场合也会出现，目前着重在 btfs 应用。 btfs 内部主要分为两个角色，五个合约。 两个角色： renters：租户，有存储数据的需求 host：主机，可以存储数据 五个合约： Vault contract：租户需要存储数据时，需要通过保险库合约向主机发送特定金额的支票来支付费用；主机可以通过这个合约，兑现支票到自己钱包 Staking contract：质押合约。主机必须质押 btt，当租户需要上传文件时，通过这个合约确定找谁存储 Proof-of-storage contract：存储证明合约。主机托管文件后，需要定期生成文件存储证明并提交到存储证明合约，如果错过提交期间，会被处罚 Airdrop contract：空投合约。主机将根据文件大小和存储时长从 btfs 收到 btt 空投。 Price contract：价格合约，更新全网存储价格。 这个架构图中缺失了两个合约，更关注整个存储过程。租户通过价格合约获得当前存储价格，然后质押合约会给出主机推荐，然后租户向保险库合约进行质押，同时向主机节点发送需要保存的文件和支票，主机完成存储后，（会向存储证明合约发送存储证明）并向保险库合约兑换支票。这样就实现了两个不信任的角色之间的交易。 部署方案 为了实现单机多节点，同时对性能需求进行限制，选择使用 docker 单机部署的方案。（后期可根据需求上 k8s 方案）。 镜像获取 # 方法一（简便） docker pull ghcr.io/bittorrent/go-btfs:latest # 方法二（复杂，但精准） git clone https://github.com/bittorrent/go-btfs cd go-btfs docker image build -t btfs_docker . 配置 volume 主要是三个目的：数据转移，明确定义明确使用，复用一些数据。目前还不明确 btfs 那些数据可以复用，暂时先不复用。 ...

2022-04-26-进入btfs测试网 Block Chain BTFS btfs 测试网：进入及测试 连接测试网 首先需要确认测试网当前运行的程序版本，不然无法进入 建议使用本地编译的方案，如果编译失败，可以适当降低 go 版本 不同版本的btfs的测试网进入方法不一样，在 20220426 这个时间点，需要在初始化 btfs 节点时制定参数：./btfs init -p storage-client-testnet 执行 ./btfs daemon，进入长期运行模式需要触发两个智能合约，所以需要从 测试网水龙头 获取点初始资金 正常运行后，查看账户地址会出现三个交易：一个水龙头发钱，两个智能合约触发。会出现一个 vault。打开本地的 dashboard 配置钱包 测试网水龙头发送的是 btt，而 btfs 内部的交易需要使用 wbtt，而在 2.0 版本中，没有直接的 btt 兑换 wbtt，必须要走合约。 先在 metamask 添加测试网络： - 网络名称（Network Name）：BitTorrent Chain Donau - RPC URL（RPC URL）：https://pre-rpc.bt.io/ - 链ID（ChainID）：1029 - 符号（Symbol）：BTT - 区块浏览器URL（Block Explorer URL）：https://testscan.bt.io/ 然后导入密钥的方式先获得钱包，然后向 0x107742EB846b86CEaAF7528D5C85cddcad3e409A 发送请求。 如何获得 WBTT？ 打开metaMask钱包，切换到BTTC测试网（相关参数参考地址[https://doc.bt.io/v1/doc/#network-details](https://doc.bt.io/v1/doc/#network-details)），点击SEND按钮，需要注意三点。 1 - 您需要填写WBTT的合约地址，0x107742EB846b86CEaAF7528D5C85cddcad3e409A。 2-金额：需要填写要兑换多少BTT，BTT和WBTT是1:1的兑换关系 3-Gas Fee（gwei），需要改成300000。_ 然后就可以把 wbtt 转入到保险库，先试试上传文件。 功能测试 btfs add <file-name> btfs storage upload 常见错误

2022-04-25-BTT Block Chain [[BTFS]] BTT 背景：存储和带宽类项目。 项目进度：压力测试 目标： 盈利：一台机器 1000，六个月回本 寻求爆发点 挖矿逻辑：奖励逻辑 一些问题： 常规 Q：BTT、BTTC、WBTT的区别？ A：BTTC 指的是 BitTorrent Chain。BTT 是发行货币，用于 BTTC 的 gas 消耗。WBTT 在 BTFS 节点之间上传或接收文件时用作货币。BTT 和 WBTT 可以 1:1 互相转化。 收益 Q：收益模式？ A：按照官方的说法，目前对于btfs节点来说，收益分为空投+存储合约。空投的逻辑在另一个问题下在谈。存储合约在 v2.1.2 下的收益是 3750.00 WBTT （GB/月）。还有一种收益模式是对 validators 投票，然后获取收益，等于是质押收益。 A：存储合约，目前来看，租用者 和 存储者 的付出和收益是一致的，考虑到 gas fee，依靠自身集群的存储合约无法获得收益。 A：空投逻辑。 A：质押收益在 pos 下是可行的，但这会根据当前代币释放量被稀释。 部署配置 Q：实际环境如何部署，直接docker？本地编译？docker 指定性能？ A：目前选择 docker 方式进行部署，直接使用官方提供的镜像，未指定性能限制参数。 Q：服务器如何登陆？管理页面怎么打开？ A：需要vpn进入到内网，然后进行登陆。管理页面需要在任意一个btfs web内设置 API 端口 Q：端口（服务）是怎么分配的？ A： 低优先级问题： Q：尝试本地docker编译运行后，使用指令会出现：Error: lock /data/btfs/repo.lock: someone else has the lock？ Q：查看chain info，出现 panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x255c7f7] 相关网站： ...

2022-04-14-ETH学习 Block Chain ETH 学习 以太坊也是一种链，它实现了去中心化的合约，使得应用场景更多。相比于比特币，它的设计更加工程化，偏向于实际应用。 账户 160 位二进制组成，简单记作 40 个 16 进制数。 账户模型更符合现实中交易的逻辑。 可以天然性的抗双花问题。 用nonce改变对抗replay attack（收款方恶意攻击） 两类账户： externally owned account：公私钥生成 balance：余额 nonce：交易计数器 smart contract account：智能合约账户，无法发起交易 balance nonce code：发布时确认，无法修改 storage 状态树 状态树需要保存的就是所有账户的状态，包括但不仅仅包括余额。在整个eth链上，理论上可以存在 2^160 个账户，这是一个很庞大的量，需要解决这些账户的增加、查找、更新等操作，就需要寻找一种更好的数据结构。最终的选择是：Modified Merkle Patricia State Trie。 由于需要实现防篡改性，还是要基于默克尔树进行设计。像是 BTC 里的默克尔树就并不适用，这是因为： btc 的默克尔树保存的是交易记录，每一个区块生成一个全新的默克尔树，该树产生后就不再需要更改。而账户的状态是经常会有变动的（每次交易都意味着账户的状态变动）。所以普通默克尔树成本太高了。 btc 的默克尔树不支持快速的查询，查询性能为O(n)，但由于存放的是交易数据，每个区块内都不会超过4000个，所以可以忍受。而 eth 的账户太多了，查询性能 O(n) 是无法忍受的 这里就需要一种新的结构，检索树。检索树是一种多叉树，类似于字典的索引，对于eth的账户场景来说，它可以是高度为 160 的二叉树，也可以是高度为 40 的十六叉树，但无论哪种方式，它的查找效率都大大提高。但它的效率还是不够高，它的存储空间也是个问题。 针对上述问题，可以用 Pactricia Trie 的方式解决。这是一种数据压缩技术，它可以根据多个数据相同的部分进行压缩（例如数据中间都有abcdefg，那么一个节点就存储abcdefg，它的高度立刻减少了7，但是数据不会丢失）。这个方案需要一个前提，就是数据足够分散，数据越分散，压缩的效果越好。例如有10个160位的二进制数，使用Trie，必定高度为160，但使用了 Pactricia Trie，哪怕 10 个数很相似但又不一致，它的高度最高也只会是10。而eth的账户系统确实很分散。设计上，理论有2^160个账户，但现实中完完全全用不到这么多账户(一亿亿个账户也才2^56,这意味着全球70亿人民一人14285714个账户)，账户这么设计更多的是为了防止hash碰撞。 有了上述的说明，就可以推导出 Modified Merkle Patricia State Trie。一种变形的使用hash指针的Pactricia Tria。详细的理解可以参考:Modified Merkle Patricia Trie — How Ethereum saves a state ...

2022-04-12-BTC学习 Block Chain BTC 学习笔记 密码学原理 hash 三个特性 collision resistance：碰撞抵抗，防止两个不同的输入生成同样的输出 hiding：无法通过hash的输出推断出hash的输入，这需要很大的输入集，并且输入集足够分散 puzzle friendly：无法预测hash的输出，从而使得挖矿过程没有捷径 设计原则：difficult to slove,easy to verify 比特币使用的 hash 函数为：SHA-256（Secure Hash Algorithm-256 bit） 账户 创建账户的过程不需要中心化的操作，仅需要符合非对称加密的公钥/私钥。 签名 签名使用X的私钥 验证签名使用X的公钥 不仅账户创建是需要随机元，签名的时候也需要随机元 基础数据结构 hash 指针 hash pointer is a pointer with hash degist,avoid tamper-evident problem. Block chain is a linked list using hash pointers 默克尔树 一种二叉树，叶子结点为数据块，保存交易；非叶子结点则为叶子结点的hash值。用于实现 merkle proof。 轻节点如何判断一个交易是否包含在一个块内？根据任意一个叶子结点，算出其hash，同时向全节点请求（二叉树）另一边的hash，最后算出根hash，和链上的数据进行比对。 同理，存在有序默克尔树，叶子结点按照hash进行排序，在 BTC 中没使用到。 数据结构 Block Header version hash of previous block header merkle root hash target nBits nonce Block Body transaction list 防范双花问题 在整个链上，除了hash指针指向前面的数据防止整个链被篡改，链上的交易数据还需要一个hash指针指向币的来源。 ...

2022-04-03-文件描述符 Linux [转载]Linux 文件描述符 维基百科：文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。 转载信息 作者：waterandair 发表时间：2017-07-03 原始链接：文件描述符（File Descriptor）简介 一、文件描述符概念 Linux 系统中，把一切都看做是文件，当进程打开现有文件或创建新文件时，内核向进程返回一个文件描述符，文件描述符就是内核为了高效管理已被打开的文件所创建的索引，用来指向被打开的文件，所有执行 I/O 操作的系统调用都会通过文件描述符。 二、文件描述符、文件、进程间的关系 2.1. 描述： 每个文件描述符会与一个打开的文件相对应 不同的文件描述符也可能指向同一个文件 相同的文件可以被不同的进程打开，也可以在同一个进程被多次打开 2.2. 系统为维护文件描述符，建立了三个表 进程级的文件描述符表 系统级的文件描述符表 文件系统的 i-node 表 (转到：阮一峰——理解inode) 2.3. 通过这三个表，认识文件描述符 在进程 A 中，文件描述符 1 和 30 都指向了同一个打开的文件句柄（#23），这可能是该进程多次对执行打开操作 进程 A 中的文件描述符 2 和进程 B 的文件描述符 2 都指向了同一个打开的文件句柄（#73），这种情况有几种可能 进程 A 和进程 B 可能是父子进程关系 进程 A 和进程 B 打开了同一个文件，且文件描述符相同（低概率事件） A、B 中某个进程通过 UNIX 域套接字将一个打开的文件描述符传递给另一个进程 进程 A 的描述符 0 和进程 B 的描述符 3 分别指向不同的打开文件句柄，但这些句柄均指向 i-node 表的相同条目（#1936），换言之，指向同一个文件。发生这种情况是因为每个进程各自对同一个文件发起了打开请求。同一个进程两次打开同一个文件，也会发生类似情况。 前人的思考，我们的阶梯，这部分参考自网络：链接 ...

2022-04-01-nginx日志分析 Nginx Nginx 日志分析 统计请求的top10 其本质是考验对 shell 的部分指令的使用程度，难度不大，主要考察 awk、sort、uniq、head和管道的使用。 # 先通过awk获取需要的数据列、然后进行简单的排序使相同的ip都在一片区域、再使用uniq -c去重，同时给出去重的数量、再通过sort -n -r对去重数量进行反向排序、最后取前十条数据 awk '{print $1}' access.log|sort|uniq -c|sort -n -r|head -10