您正在查看: surou 发布的文章

Besu 基于 Java 的企业级 Apache 2.0 许可以太坊客户端

Besu 是一个 Apache 2.0 许可的、兼容 MainNet 的、用 Java 编写的以太坊客户端。
https://github.com/hyperledger/besu

kaleido chain 测试链部署

由于在调研Algorand共识,所以最近阅读和测试相关的链实现,此篇将主要讲解kaleido的私链部署测试。
由于相关项目基本已经很久不更新,文档社区匮乏,只能阅读代码,反向推出运行参数和步骤。

编译源代码

参考《kaleido 编译与测试》,执行编译相关子程序

make all

最终kaleido\build\bin会生成genesis程序,下面会用到

genesis.json创建

启动私链,首先需要准备bios节点配置
阅读相关代码(github
可以使用genesis程序进行生成,首次直接运行genesis

Hint: You must make a minerkey before making genesis.

提示需要先生成minerkey,继续跟进
阅读相关代码(github

    makeMinerKeyCommand = cli.Command{
        Action:    utils.MigrateFlags(makeMinerKey),
        Name:      "makeminerkey",
        Usage:     "Generates a miner key for mining",
        ArgsUsage: " ",
        Flags: []cli.Flag{
            utils.DataDirFlag,
            utils.MinerStakeOwnerFlag,
            utils.MinerKeyCoinbaseFlag,
            utils.MinerKeyStartFlag,
            utils.MinerKeyLifespanFlag,
        },
        Category: "MINER COMMANDS",
        Description: `
The makeMinerKey command generates a miner key for mining.
If the key already exists, just return it.

可以使用kalgo加上参数makeminerkey进行生成,参考有限文档例子如下

mkdir $PWD/data
export KALEIDO_HOME=$PWD/data
echo $KALEIDO_HOME

./kalgo makeminerkey \
--miner.stakeowner 0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0 \
--minerkey.coinbase 0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0 \
--minerkey.start 1

0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0修改为自己的地址
执行生成后,返回

MinerKey: 0x39fb25e90000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000006400000000000000000000000048f155527f25eb1d4cb2aa32b7e84692aa0025c003ada2cdce38f8fd0aafbaf5542a03a78b90b93ce594e0568760ba952e2b1f534566f9bde28e7b7d6ba8a369e0a4a6b419b12b86cb577c374cd257ef0a5a5645
Details:
    miner = 0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0
    coinbase = 0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0
    start = 1
    end = 1000000
    lifespan = 100
    vrfVerifier = 0x03ada2cdce38f8fd0aafbaf5542a03a78b90b93ce594e0568760ba952e2b1f53
    voteVerfier = 0x4566f9bde28e7b7d6ba8a369e0a4a6b419b12b86cb577c374cd257ef0a5a5645
GenesisStorage:
    0xf542409778bcdead44d9b45f4b07b70b047acb90dcda73c55b6b72088ca2fefd = 0x48f155527f25eb1d4cb2aa32b7e84692aa0025c0000000640000000000000001
    0xf542409778bcdead44d9b45f4b07b70b047acb90dcda73c55b6b72088ca2fefe = 0x03ada2cdce38f8fd0aafbaf5542a03a78b90b93ce594e0568760ba952e2b1f53
    0xf542409778bcdead44d9b45f4b07b70b047acb90dcda73c55b6b72088ca2feff = 0x4566f9bde28e7b7d6ba8a369e0a4a6b419b12b86cb577c374cd257ef0a5a5645

以上仅为测试数据,对于自己相关私有数据请注意保管

由于cmd/genesis/main.goconsensus/clique/clique.go已写死了0x0e09768B2B2e7aa534243f8bf9AFdC145DdA8EDa为测试数据,所以我们可以修改对应代码,也可以拿测试地址生成minerkey,然后生成genesis.json然后再手动修改对应的地址和数据。
切记替换地址时,(github

contracts.MinerAddress: {
        Balance: common.Big0,
        Code:    common.FromHex(contracts.MinerBinRuntime),
        Storage: map[common.Hash]common.Hash{
            common.HexToHash("0x06ff3c55f357d4545a14dcc167670bf1dcc8bb45dcd90fa4a085a02a39da3a8a"): common.HexToHash("0x45ec182edc6774c9a2926172f1fd996e59b58ced000000640000000000000001"),
            common.HexToHash("0x06ff3c55f357d4545a14dcc167670bf1dcc8bb45dcd90fa4a085a02a39da3a8b"): common.HexToHash("0xf88a8d844c217531a38d6019ea671652340fe0d899996250bccce13af99933de"),
            common.HexToHash("0x06ff3c55f357d4545a14dcc167670bf1dcc8bb45dcd90fa4a085a02a39da3a8c"): common.HexToHash("0x6e8f4a7c7651766722dd7fb9d7a97cd28678a1cefb12631580a7ffe90a910b8f"),
        },
    },

Storage中的数据,要替换成上面执行kalgo makeminerkey返回的数据中的GenesisStorage对应的数据,不然检查不通过(github)会报bad signature

此时按照常规eth启动步骤执行即可,细节不再单独讲解

./kalgo --datadir ./data init genesis.json
./kalgo --config geth.toml  --nodiscover

./kalgo attach ipc:./data/geth.ipc

添加新节点

同上为新节点创建minerkey

mkdir $PWD/data
export KALEIDO_HOME=$PWD/data
echo $KALEIDO_HOME

./kalgo makeminerkey \
--miner.stakeowner 0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa \
--minerkey.coinbase 0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa \
--minerkey.start 1

返回

MinerKey: 0x39fb25e900000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000064000000000000000000000000bb93fcc2bb90d46255c43dd398a1a372e12be6aa474d81ab830043ccdd099147b7b90f073d8b2bda52892d40e8601cfcfbb03a2e35c6ae655cecc87a4c977435e36c8d88ea2950e1cec425e42909b934adbc1de8
Details:
    miner = 0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa
    coinbase = 0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa
    start = 1
    end = 1000000
    lifespan = 100
    vrfVerifier = 0x474d81ab830043ccdd099147b7b90f073d8b2bda52892d40e8601cfcfbb03a2e
    voteVerfier = 0x35c6ae655cecc87a4c977435e36c8d88ea2950e1cec425e42909b934adbc1de8
GenesisStorage:
    0x3a624f62c38b6bf3cf93859680439fb3332269b77ec12e8e022bf7be4a569857 = 0xbb93fcc2bb90d46255c43dd398a1a372e12be6aa000000640000000000000001
    0x3a624f62c38b6bf3cf93859680439fb3332269b77ec12e8e022bf7be4a569858 = 0x474d81ab830043ccdd099147b7b90f073d8b2bda52892d40e8601cfcfbb03a2e
    0x3a624f62c38b6bf3cf93859680439fb3332269b77ec12e8e022bf7be4a569859 = 0x35c6ae655cecc87a4c977435e36c8d88ea2950e1cec425e42909b934adbc1de8
mkdir -p ./data/kalgo/minerkeys
cp ~/.kaleido/kalgo/minerkeys/0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa-0-1000000.bin ./data/kalgo/minerkeys
./kalgo makeminerkey \
--miner.stakeowner 0x10210572d6b4924Af7Ef946136295e9b209E1FA0 \
--minerkey.coinbase 0x10210572d6b4924Af7Ef946136295e9b209E1FA0 \
--minerkey.start 9500


mkdir -p ./data/kalgo/minerkeys
cp ~/.kaleido/kalgo/minerkeys/0x10210572d6b4924Af7Ef946136295e9b209E1FA0-0-1000000.bin ./data/kalgo/minerkeys


myaddr = '0x10210572d6b4924Af7Ef946136295e9b209E1FA0';
hash = eth.sendTransaction({
    from: myaddr, 
    to: '0x1000000000000000000000000000000000000002', 
    gas: 200000, 
    gasPrice: 20000000000, 
    data: 
'0x39fb25e9000000000000000000000000000000000000000000000000000000000000251c000000000000000000000000000000000000000000000000000000000000006400000000000000000000000010210572d6b4924af7ef946136295e9b209e1fa04141f8e905b628d3657b151a62c1414c4cc4f554d24bc16971c8233b761879d09b8f95e47a6f9662b78198c45ff986153c1e3316ede5cbfae09c6f927d374bd2'
});
admin.sleepBlocks(2);
eth.getTransactionReceipt(hash);


personal.importRawKey("8d91c6c7a494a4373...0715","j7OseEMVQ3Trna6gWdkp")
personal.unlockAccount("0x10210572d6b4924Af7Ef946136295e9b209E1FA0","j7OseEMVQ3Trna6gWdkp",0)



nohup ./kalgo --config geth.toml --networkid 1001 --unlock "0x10210572d6b4924Af7Ef946136295e9b209E1FA0" --password ./password --mine --miner.stakeowner "0x10210572d6b4924Af7Ef946136295e9b209E1FA0" --nodiscover --etherbase 0 --verbosity 4 2>> ./geth.log &

personal.unlockAccount("0xf8329ea42489c2164f44a81deb3be22c2c456109","j7OseEMVQ3Trna6gWdkp",0)
eth.sendTransaction({from: "0xf8329ea42489c2164f44a81deb3be22c2c456109", to: "0x10210572d6b4924Af7Ef946136295e9b209E1FA0", value: web3.toWei(25000000, 'ether')})


admin.addPeer("enode://e20d5cb1c726bb5f8bcc5c3b91255e7fcf459add7584cf6becbb99715f2f84334f14233843bb50ce68c71c4f1b6cfeaff3294cec85a488f363428476010651b1@172.31.204.223:32668?discport=0")
admin.addPeer("enode://95b41257c7da4bd0a98e81cb636b833c36693a3ab76ff55987663455b186dac96437d785b7bb6c5d5335bae91402f227d99a395c1dfe31663a891eb6e5d90140@172.31.204.224:32668?discport=0")



./kalgo --datadir ./data init genesis.json
./kalgo --config geth.toml  --nodiscover

./kalgo attach ipc:./data/geth.ipc

参考

https://docs.kaleidochain.io

Algorand 共识算法

2018年是公链技术爆发的一年,诞生了诸多从共识方面创新的项目。由于目前人们普遍认为存在区块链“不可能三角”,这些共识往往要在性能、安全、去中心化、激励机制中做出取舍。例如,EOS达成每秒数千次交易速度是以牺牲去中心化为前提的。然而“不可能三角”从来没有像FLP、CAP这些分布式系统定理一样得到严谨的数学证明,因此有些人认为打破“不可能三角”是有可能的。可验证随机函数VRF被认为是一个有前景的方向。本次为大家带来最近热度非常高的Algorand项目的分析。

1、Algorand共识算法简介

Algorand共识算法是图灵奖获得者Silvio Micali在2017年底提出。Michali是MIT的教授,是一位密码学家和计算机理论学家,在伪随机数以及零知识证明领域很有名。
Algorand共识算法的论文的下载地址:https://people.csail.mit.edu/nickolai/papers/gilad-algorand.pdf

Algorand采用了VRF函数,并结合账户的余额比例,随机确定区块生成以及投票人角色。

所谓VRF(Verifiable Random Function)就是可验证随机函数。

随机数对于区块链技术来说很关键。 本质上,分布式账本的核心问题就是随机选择出块人的问题,这个随机性要能被全网确认,并且不能被操控,也不能被预测, 否则恶意节点通过操控这个随机数就可以操控长链,从而实现双花攻击。

PoW的方案是让大家进行算力竞赛,设置一个计算哈希的难题,谁先算出来谁赢,算力高的赢的概率高,算力低的赢的概率低,以这样的方式保证胜出者是随机的。投入的算力能够体现在哈希值上, 这样全网能够验证,并选择包含最多算力的那条链。恶意节点只能通过提升自己的算力来增加攻击成功的概率。

PoS的方案是选举,大家不用浪费电力去进行算力竞赛,而是文明一点,随机选举一个节点来出块,并且被选中的概率和它拥有的份额相关。 如果“随机”这一步没有问题的话,恶意节点只能通过增加自己的份额,增加自己被选中的概率,从而增加双花攻击的成功概率。 这里有一点比PoW的方案要好就是,要实现攻击,先得成为持币大户,如果攻击成功币价大跌,攻击者也会承受最大的损失。

那么接下来的核心问题就是,这个不能被操控不能被预测的随机数从哪来。传统地PoS方案尝试从链上现有的数据入手,比如使用上一个区块的哈希值,上一个区块的时间戳等等来作为随机数的来源,但这些会带来额外的安全风险。 因为区块本身的信息就是节点写进去的,然后又要根据里面的信息来选举后续的出块者,存在循环论证的嫌疑,安全性不会太好。 这也是传统地认为PoS方案不如PoW可靠的部分原因。

Algorand提出的VRF能够由私钥( SK )以及讯息( X )产生一组可验证的伪随机 (pseudorandom) 数Y以及证明 ⍴。任何人都可以透过Verify函数来检验这个随机字串是否真的是该公钥对应私钥持有者,依照规定使用Evaluate函数所产生,而不是自己乱掰的。更详细一点的VRF三个函示描述如下:

•Keygen(r) → (VK, SK). On a random input, the key generation algorithm produces a verification key VK and a secret key SK pair. •Evaluate(SK, X) → (Y, ⍴) . The evaluation algorithm takes as input the secret key SK , a message X and produces a pseudorandom output string Yand a proof ⍴ . •Verify(VK, X, Y, ⍴) → 0/1 . The verification algorithm takes as input the verification key VK , the message X , the output Y, and the proof ⍴ . It outputs 1 if and only if it verifies that Y is the output produced by the evaluation algorithm on inputs SK and X .

为什么我们需要这么一个大家自己产生,却又要可以被验证的随机字串产生器呢?这是因为在Algorand的拜占庭演算法中,虽然也存在着每一轮不同的区块生产者(称为Leader)以及验证委员会(Committee, Verifiers),但并不是用「公开选举」的方式来选的,而是透过每个使用者自己对奖的方式来看看自己是不是下一轮的Leader。

algorand就是通过随机算法从一群大范围的验证者中选取一部分验证者运行BFT算法(Micali教授实现的BA*算法),从而达到提高共识的效果。

无论是在何种BFT的共识机制中,都是由Leader以及Committee来完成区块的发布以及共识决议。例如EOS的dPoS BFT是固定21个BP轮流担任Leader以及投票者、Zilliqa透过PoW加入Committee进行PBFT共识算法。这些比较直观的拜占庭共识演算法都有一个共同特征,就是大家都可以看到下一个区块的Leader是谁,以及负责协议共识的Committee是谁。这造成了一个可能的风险,就是这些区块生产者以及Committee成员容易成为DDOS或是贿赂的目标。

Algorand为了解决这种潜在的风险,利用VRF来掩盖Leader Selection的步骤。可以想像成:一般的BFT在每一轮开始时公平公开选出Leader以及Committee,Algorand则是像在每一轮开始时公布中奖号码,每个使用者都可以自己拿自己的票根对奖,中奖的人即可成为下一轮的Leader(或是Committee Verifier),但在中奖者自己表明身分前,没有人知道谁中奖,也就是没有人能预测下一轮的Leader以及Committee。当然中奖与否并不是口说无凭,中奖者需要出示中奖证明,而这个证明是大家都可以验证的,这正是我们刚刚说到的VRF。

2、Algorand共识算法缺陷

(1)现实环境的随机选择的空间并不大。

VRF是可以提供了公平且不容易收到伪造和攻击的委员会随机选择方式,但是任何随机数的生成必须依赖大的种子集合才可以有作用,在VRF中假设80%节点是诚实的,Committee需要2000个成员才够大,现实情况是不太可能有这么多成员的。

(2)完全没考虑网络延迟情况。

VRF Committee集合选举时依赖数量庞大的主机通讯的,主机之间相互沟通造成的延迟,必然大大拖慢整个系统的处理速度。

(3)没考虑节点的动态加入和退出情况。

Algorand的下一个区块的发布者是从k个区块之前的所有参与者(在k区块之前的某段链上发过交易的节点)里选。于是,恶意节点想影响下个区块的发布者,他得影响k个区块才行,当k很大的时候,这个影响也是微乎其微。于是,Algorand得到了一个无偏向的随机数产生器。不过,这个做法有一个问题——k区块之前的节点,有可能已经不在线了。而对于这一点,虽然Micali做出了解释,但是个人觉得并不符合实际情况。

(4)签名数据庞大,造成存储浪费并影响性能。

Algorand使用VRF来确定提案组与验证组,这个方式充分发挥了VRF的可验证性优势,且后验优势使得Algorand的共识体系更安全。但是,Algorand进入验证阶段,采用的是一种可扩展的拜占庭容错算法,即BA算法,参与节点通过VRF秘密抽签选出。这一设计使Algorand在验证前必须等待凭证(VRF prove)到来,才能知晓参与节点。而且,由于使用了可扩展的拜占庭容错算法,使得Algorand的验证组规模必须比较大(2000~4000人),这将导致签名数据异常庞大。根据我们的估算,在平均每组3000个验证节点的规模下,每组的签名数据长达126KB,加上其它信息,通知信息约300K,每块的签名数据可达200064*12=1M(共12组,每组3000人,至少2/3达成共识。ed25519签名数据长度是64。),远超一般门限签名几十个字节,严重浪费存储和容量(因每块存储的交易量将被占用,不存储签名又会影响安全),不仅造成存储浪费,而且更影响性能。

(5)无法构建很好的激励机制

在POW中,提案者得到提案权需要预先付出算力成本,若其提案区块有问题(交易双花),则该提案区块在全网其他节点验证必将失败,从而不但没有铸块收益,还付出了算力成本。

Algorand协议并没有设计经济激励机制,Micali教授曾回应”Algorand协议只需要进行平凡的计算,因此不需要激励”。在没有经济激励机制下,高性能带宽和服务器必然不愿意参与(因为它本身要消耗费用),整个网络会遇到网络本身无法解决的困难。

(6)存在潜在的安全问题

网络用户必须连续访问其私钥,以确定其在每一轮中的VRF状态(即验证者、提议者,或者两者都不是)。

一般认为,对于那些将大量资产存储在区块链上的个人,为了防止攻击,他们应该把私钥以冷存储的方式进行保存。而持续的验证(需要经常签名)会需要高频率地动用私钥,从而增加被攻击的风险。这显然将导致网络中很多诚实的个体(出于安全的考虑)会避免参与验证过程,从而造成区块链缺乏活力的问题。

(7)买断问题

在区块链的婴儿期,系统的通证价值通常较低,其市值也是处在相对较低的水平。Token的发行往往要经过私募-->基石-->公募 等逐步分散的过程,因此很长一段时间里币是集中在少数人手里的,因此任何POS共识都面临着EOS类似的中心化的问题。

(8)没有惩罚问题

Algorand所存在的另一个问题是,没有办法识别“离线验证者”并惩罚它们。因此,在没有惩罚措施来防止无效的情况下,没有经济激励就是一个问题,很多人会选择不为共识做贡献,因此离开这个网络。假设网络中只有10%的诚信节点在不断地进行验证,而其余节点是离线的状态,与此同时,恶意的节点选择保持在线,那其就很容易超过在线委员会节点。这使得恶意节点更容易控制共识。

总的来说,Algorand的VRF和加密抽签后验性给出了一个解决“三角悖论”的很好设计思想,但其在验证环节的设计更偏单纯的学术化理想化,导致其对网络流量、有效通讯数据等实际工程落地思考不够,严重影响了公链运行性能、节点网络规模、账本存储容量和去中心化程度。
转载:https://www.8btc.com/article/348383

kaleido 编译与测试

克隆源代码

git clone https://github.com/kaleidochain/kaleido.git
cd kaleido/

安装依赖

sudo apt-get update
sudo apt-get install -y git build-essential autotools-dev libtool autoconf automake pkg-config cmake libboost-all-dev

创建go mod

rm -rf vendor/
go mod init
go mod tidy

编译源码

make kalgo

最后编译完成后

Done building.
Run "/kaleido源代码目录/build/bin/kalgo" to launch kalgo.

多部门重拳整治虚拟币炒作 “挖矿”活动被彻底清理

对虚拟币的整治再次升级。

9月24日,人民银行等十部门再发新规整治“虚拟币炒作”,明确了虚拟币相关业务活动属于非法金融活动。同日,国家发改委等十一部门联合发文,整治虚拟币“挖矿”,要求严禁新增项目投资建设、加快存量项目有序退出。

虚拟币市场闻声下跌,比特币家园数据显示,比特币价格当日下跌超4%,以太币跌超7%。星火矿池宣布配合最新的行业监管政策,将关闭中国大陆境内矿池服务。25日,虚拟币交易平台火币、去中心化钱包TokenPocket也停止对国内用户提供部分服务。BHEX、BiONE等小交易平台宣布永久关闭。

业内专家普遍认为,新规出台再次表明了监管部门对虚拟币强监管的高压态度,并对此前没有明确规定的定价服务、信息中介等“灰色地带”进行了厘清,杜绝了炒币者的幻想,防范了相关金融风险。

虚拟币相关业务为“非法金融活动”
9月24日,人民银行官网发布了《关于进一步防范和处置虚拟货币交易炒作风险的通知》(以下简称《通知》)。

《通知》提出构建多维度、多层次的风险防范和处置体系,要求金融机构和非银行支付机构不得为虚拟币相关业务活动提供服务;加强对虚拟币相关的市场主体登记和广告管理;加强对虚拟币相关的互联网信息内容和接入管理等。

“与以往的政策规范相比,《通知》在明确虚拟币和相关业务活动本质属性方面提出了新的定义。”中国银行法学研究会理事肖飒表示,一是直接挑明USDT(泰达币)属于虚拟币,不受我国法律保护;二是为虚拟币提供“定价服务”也属于违法,未来会被取缔;三是虚拟币交易“信息中介”模式,不再是灰色地带,已归于非法范畴;四是境外交易平台的境内人员,不能逃避法律责任;五是涉虚拟币投资交易的合同无效,理由是违反公序良俗。

北京链通律师事务所主任丁飞鹏在接受《证券日报》记者采访时表示,《通知》首次明确虚拟币相关业务活动的性质,目前主流虚拟币交易平台的“场内币币交易”和“场外OTC”的组合模式在定性上已经没有争议了,虚拟币之间的兑换业务或为国内用户提供这种兑换业务已经被明确定义为“非法金融活动”。

丁飞鹏进一步表示,《通知》发布前,司法实践中对虚拟币的性质的定义各不相同,有的地方认为属于“虚拟商品”“民间金融资产”,应当受到法律的平等保护;有的地方认为投资虚拟币属于非法,不受法律保护。《通知》发布后,司法机关可以“违背公序良俗”为由,宣布相关民事法律行为无效,由此引发的损失由参与者自行承担。

工信部工业互联网区块链重大项目评审专家、中国移动通信联合会区块链专业委员会主任委员陈晓华对记者表示,《通知》提出,从部委协同联动、强化属地落实、全方位监测预警,各省建立信息共享和快速反应机制等方面进行监管,监管力度更大、范围更广、不留死角,体现了建立常态化工作机制,始终保持对虚拟币交易的高压打击态势。

整治虚拟币“挖矿”严禁增量、妥处存量
同日,国家发改委等十一部门出台《关于整治虚拟货币“挖矿”活动的通知》(以下简称《通知》)。

《通知》指出,按照“严密监测、严防风险、严禁增量、妥处存量”的总体思路,充分发挥各地区、各部门合力,加强虚拟币“挖矿”活动上下游全产业链监管,严禁新增虚拟币“挖矿”项目,加快存量项目有序退出。

“虚拟币‘挖矿’活动能耗大、耗电高,其盲目无序的发展给节能减排造成不利影响。”宝新金融首席经济学家郑磊对《证券日报》记者表示,在电煤价格高居不下,生活和生产用电受到碳排放考核影响的情况下,各地更应加快清退虚拟币“挖矿”项目。

深圳市信息服务业区块链协会会长郑定向对《证券日报》记者表示,目前,虚拟币挖矿造成了能源的过度消耗,增加了碳排放,并且矿机的快速更换会产生更多的电子垃圾处理排放,这与我国碳中和发展理念背道而驰,不利于实现双碳目标。

具体来看,在全面梳理排查虚拟币“挖矿”项目方面,《通知》提出梳理排查存量项目,保证本地虚拟币“挖矿”排查工作不留空白;梳理排查在建新增项目;加强异常用电监测分析。

事实上,今年6月份,内蒙古、四川、青海、新疆等地方政府积极行动,清退虚拟币“挖矿”企业,无论是火电为主还是水电为主的“挖矿”企业均遭清理整顿。9月份,河北、甘肃再次针对虚拟币“挖矿”和交易行为部署专项整治行动。并提出后续将进行常态化监管,常态化开展清查虚拟币矿机“挖矿”、违约用电和窃电等工作。

肖飒称,《通知》明确把“挖矿”活动列为淘汰类产业,并不给予任何支持。严禁以数据中心名义开展虚拟币“挖矿”活动。要求地方不要给“挖矿”企业财税支持和金融服务,从资金来源上打击“挖矿”企业。

丁飞鹏称,“挖矿”企业对于电价极为敏感,《通知》明确将虚拟币“挖矿”项目纳入“淘汰类”企业电价,实行加价。明确禁止虚拟币“挖矿”项目参与电力市场,直接切断了一些虚拟币“挖矿”项目的退路。