日前，Casper节点1.3版本正式发布，该版本的casper节点加入了智能合约功能，提升网络的同时改善了对合约内大型数据结构的支持（改善了对本地密钥的支持），合约作者也能够通过新增的get_call_stack方法来验证合约的直接调用者。
开发团队还为Casper系统加入了基础的NFT合约。
版本详情
提升节点RPC
开发者现在可通过新的可接收源块哈希或state_root_hash的RPC端点query_global_state来查询Casper网络的全局状态，之前全局状态只能通过state_root_hash查询。更新后的Rust客户端已新增调用节点RPC的query-global-state命令。
Casper网络验证器轮换按照链上拍卖合约进行。通过RPC方法state_get_auction_info可查询系统合约状态。之前查不到历史信息，现在RPC接收block-identifier参数，可查询历史拍卖信息。
之前版本中，查询账户信息的全局状态需要RPC调用通用的state_get_item，产生了不必要的开销。1.3版本后，RPC调用新增的state_get_account_info将可直接返回账户细节。
智能合约和应用开发进展
Casper节点通过事件流来发送区块链事件。系统发送的事件分为三大类，部署（交易）事件、最终签名（由共识参与者发出，表示区块已受理）及系统事件。所有这些事件之前都从同一端点发出。1.3版本后，旧端点将停用，节点将有三类独立的事件流。请访问GitHub了解新端点（https://github.com/casper-network/casper-node/pull/1472）及部署流变化的细节（https://github.com/casper-network/casper-node/pull/1634）。
Casper协议使用wasm来支持图灵完备的智能合约，创建的合约可通过智能合约API中的call-contract方法来调用其他合约。不过，这样做无法验证合约调用者，存在安全隐患。新增的get_call_stack方法可用来验证合约的直接调用者。更新的拍卖合约已包含该方法，可基于合约的直接调用者，而非发起部署的用户账户来验证功能。
1.3版本前，由于本地密钥和合约储存在不同的层上，导致两个不同版本的合约可访问同一本地密钥下的数据，造成了全局状态的版本问题。CEP 39建议，弃用本地密钥并在储存层增加字典密钥API作为单独的密钥空间（https://github.com/mpapierski/ceps/blob/ee-1212-local-key-proposal/text/0039-dictionary.md)。合约开发者可在单独的密钥空间中存储数据，在合约中显示为前缀为URef的地址。更多细节可访问GitHub（https://github.com/casper-network/casper-node/pull/1467/commits）。
网络优化
在同时运行绑定（验证）和非绑定节点的网络中，网络组件会在握手时检查密钥是否属于绑定验证器，验证节点间的消息传递将优先于非绑定节点。一旦网络带宽受限，所有通信将优先保障绑定验证器，以保证共识信息的传递。请求率可通过节点的config.toml文件配置。
以前，试图加入网络的大量新用户不做为下载区块信息的备用源。现在，当同步线性链时，已可从这类用户下载区块信息。
提升交易（部署）流程
Casper节点为两类交易保留了区块空间，即通证转账和wasm部署。之前，无法从哈希层面区别这两类交易，现在它们可在区块验证器中验证，在出块器中分离。之前，由于部署接收器每隔固定间隔接收一个部署到区块上，所以部署需在部署缓冲区中等待轮间隔（round_duration，1分钟），现在，只要部署信息被传播即可缓冲，并记录在块。
作者声明：以上内容仅供参考，不作为任何投资建议，如您据此投资，一切风险自负，币圈有风险，投资需谨慎。
精彩评论