Hello, fellow Rustaceans and those curious about Rust. The Hyperledger Sawtooth team is using Rust for new development, so these are exciting times for both Rust and Hyperledger Sawtooth. Rust is a new language that is quickly growing in popularity. The Hyperledger Sawtooth community is using Rust to build components to give application developers and administrators more control, more flexibility, and greater security for their blockchain networks. This blog post will give an overview of some of the new components being built in Rust.
Hyperledger Sawtooth was originally written in Python, which was a good choice for initial research and design. In 2018, the Sawtooth team chose the Rust language for new development. A key benefit is that Rust supports concurrency while also emphasizing memory safety. Several new core components, transaction processors, and consensus engines have already been written in Rust.
Compared to Python, Rust’s most noticeable feature is the expressive type system, along with its compile-time checks. Rust has ownership and borrowing rules to guarantee at compile time that an object has either only one mutable reference of an object or an unlimited number of immutable references. This feature of Rust forces the developer to account for all possible error and edgecases, making our interfaces more robust as we design them.
The validator’s block validation and publishing components are a good example of our recent interface changes. Before release 1.1, these components were heavily tied to PoET, the original consensus in Hyperledger Sawtooth. In addition, they were largely synchronous, where committing a block started the process of building a new block to publish. As we implemented the consensus engine interface, we took the opportunity to rewrite these components in Rust, which helped us to separate them more cleanly. Now there are three separate asynchronous tasks—block validation, block commit, and block publishing—that share a small amount of information. For example, the block publishing component is informed when batches are committed so that it can take them out of a pending queue, but none of the tasks starts either of the other tasks. For more information, see the block validation and block publishing components in the sawtooth-core repository.
This clean separation of tasks allows the new consensus interface to function correctly and makes it easier to develop new consensus engines. The Sawtooth team has already written two new engines in Rust: Sawtooth PBFT and Sawtooth Raft (which uses the PingCap raft library, raft-rs). The Sawtooth team is proud of the work we have done on these consensus engines, and the flexibility it provides Sawtooth community members who are building a blockchain application.
Rust also excels in its support for compiling to WASM, which can be used as a smart contract. Hyperledger Sawtooth already had Seth, which supports running Ethereum Solidity smart contracts using a transaction processor, but now has Sawtooth Sabre, a transaction processor that runs a WASM smart contract that is compiled from Rust to the WASM target. Sawtooth Sabre includes an innovative feature: using registries for namespaces and contracts. The namespace registry lets administrators control what information a contract can access. The contract registry lists versions of the contract, along with a SHA-512 hash of the contract, giving application developers confidence that the correct contract is registered. Sabre supports API compatibility with the Sawtooth Rust SDK, so developers can write a smart contract that can run either within Sabre or natively as a transaction processor, depending on the deployment methodology.
Rust has also influenced how changes to Hyperledger Sawtooth are handled. Our new RFC process is modeled after Rust’s RFC process, which provides a community-oriented forum for proposing and designing large changes. The Hyperledger Sawtooth team has put effort into a community-oriented design process at sawtooth-rfcs. The consensus API RFC is a good example: The guide-level explanation clearly lays out the purpose and reasoning behind the new component, then has a reference-level explanation of the technical details needed to guide implementation. The Sawtooth RFC process has been a good way to involve the larger Sawtooth community in driving the design and implementation of Sawtooth.
What’s next for Rust in Sawtooth? In 2019, the Sawtooth team is rewriting the remaining Sawtooth validator components in Rust. That means the networking and transaction processing components will be getting an overhaul. Expect that the networking components will be redesigned. The transaction processing components will have minor changes internally, while keeping a stable API. In both cases, there will be an increase in performance and stability thanks to Rust.
To learn more about Rust in Hyperledger Sawtooth, check out our recent changes:
- The block validation and block publishing components in sawtooth-core.
- The new consensus interface and consensus engines:
- Sawtooth Sabre
- The RFC repository at sawtooth-rfcs
About the Author:
Boyd Johnson is a Software Engineer at Bitwise IO who has worked on many core components of Hyperledger Sawtooth, including transaction processing components in Python and block validation and block publishing components in Rust. While originally a committed Pythonista, he has oxidized into a Rustacean.
New JAX Mag issue: Technology nightmares – Horror stories for the brave
New year, new JAX Magazine issue. If you’re looking for something light after overindulging on Christmas goodies, this is not it. The new issue is not for the faint-hearted as it presents a list of technology nightmares that you should avoid and learn from. Download it for freehere.
2019 is the year you become an expert: JAXenter Masterclass courses are here
Is your New Year’s Resolution to hit the books? Or perhaps you are looking to grow your skills and become an outstanding expert in your field? Regardless of your resolution, we are proud to help you make 2019 the year of growth with our new JAXenter Masterclass series. Our experts share their know-how in these hands-on workshops dedicated to bringing you up to the top.
Hyperledger Fabric 1.4 marks a very important milestone
Hyperledger Fabric is becoming one of the most important frameworks for blockchain development. Just a few months ago, it was announced that this Hyperledger project will support Ethereum Virtual Machine (EVM) bytecode smart contracts. Therefore, Hyperledger Fabric is now more accessible to developers who have already started working with Ethereum and its associated tools.
The latest release of Hyperledger Fabric, v1.4 marks a very important milestone: it is the first LTS release. This means that the Fabric maintainers will provide bug fixes for a period of one year [from the date of release: January 10, 2019]. Take a closer look here.
On the road to Angular v8
It’s time to leave Angular v7 behind and look towards the future, which, in our case, is Angular v8. We still have a couple of months left but we look forward to embarking on a new journey.
Case in point: 7.2 is here and brings a few bug fixes. Check out the details here.
GitHub is stepping up its game: Free private repos for everyone
Big news coming from GitHub with a New Year’s resolution that thrilled the developer community. Last week, GitHub announced two major updates, namely the unlimited free private repositories, and a unified Enterprise offering. But is your opinion of GitHub’s big announcement? Let us know in the poll at the end of this article.
Write operators for databases in Kubernetes with KubeDB
Running production quality databases in Kubernetes can be quite a hassle. But now you can count on KubeDB to solve your problems. KubeDB is a framework for writing operators for any database that support certain requirements. Check out our review here.
JDK 12 patrol
Last month, we saw JEP 326: Raw String Literals getting dropped from the JDK and we had a closer look at the reasons behind the decision and the community’s feedback. Nonetheless, the conversation on the feature and its function continues. Follow our thread here and find out all the details.
Hyperledger announced it was introducing the first long term release of its Fabrik platform called Fabrik 1.4 LTS. With this move, the project is one step closer to fully establishing its Hyperledger Fabric network
Hyperledger is accelerating its blockchain Fabrik integration by enhancing its blockchain-based technology platform with its latest release called Fabric 1.4 LTS. Hyperledger Fabrik has been accelerating the development and deployment of blockchain technology at its core and the introduction of Fabric v1.4 LTS represents its first long term support release.
Hyperledger Fabric’s First Long Term Support Release
According to the official site, Hyperledger Fabric is a blockchain framework implementation hosted by The Linux Foundation. Hyperledger Fabric was initially contributed by Digital Asset and IBM, as a result of the first hackathon. Envisioned as a project to promote the development of applications or solutions with a modular architecture, Hyperledger Fabric allows consensus and membership services to be “plug-and-play.”
Hyperledger Fabric leverages container technology to host smart contracts called “chaincode” that comprise the application logic of the system. Network operators and application developers have been cooperating with Fabric developers to design Fabric 1.4 with a special focus on production operations and developer ease of use.
The Fabric developers have been working with network operators and application developers to deliver v1.4 with a focus on key production-focused features of Fabric fall into four key groupings.
Serviceability and Operations
Focusing on the scalability, Hyperledger Fabric has implemented logging improvements, health checks, and operational metrics. The development of decentralized applications has also become more intuitive, as it allows a bigger focus on application logic.
Two new enhancements were added: 1) Private data collections can now be retrieved and 2) automatically enforce access control within chaincode without having to write specific chaincode logic.
Hyperledger Fabric v1.4 LTS represents the project’s first long term support release. This latest release will have special relevance as it will become the base for those beginning to deploy Hyperledger Fabric solutions into production.
Hyperledger Fabric has matured since its first release and while v1.4 LTS constitutes the first release that can be deployed easily it is bound to accelerate blockchain inclusion and adoption across a number of industries. More information Hyperledger Fabric v1.4 LTS can be found on the release notes.
A vulnerability in Cisco Jabber Client Framework (JCF) could allow an authenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of an affected system.
There are no workarounds that address this vulnerability.
This advisory is available at the following link:
Security Impact Rating: Medium
Hi, we are running SEP14 in our environment. The SEPM is hosted by another service provider. The issue we are having is that when on the internal network, we cannot view the Home, Monitors and Reports tabs when trying to log in. We have confirmed that port 8445 is open. We have also tried with the java console. Still no luck. When not on the internal network, everything works fine. May you please assist us with ideas on resolving this issue.
Thanks in advanved,
The vulnerability is due to insecure deserialization of user-supplied content by the affected software. An attacker could exploit this vulnerability by submitting crafted input to an application on a targeted system that uses the ACC library. After the vulnerable library on the affected system deserializes the content, the attacker could execute arbitrary code on the system, which could be used to conduct further attacks.
On November 6, 2015, Foxglove Security Group published information about a remote code execution vulnerability that affects multiple releases of the ACC library. The report contains detailed proof-of-concept code for a number of applications, including WebSphere Application Server, JBoss, Jenkins, OpenNMS, and WebLogic. This is a remotely exploitable vulnerability that allows an attacker to inject any malicious code or execute any commands that exist on the server. A wide range of potential impacts includes allowing the attacker to obtain sensitive information.
Object serialization is a technique that many programming languages use to convert an object into a sequence of bits for transfer purposes. Deserialization is a technique that reassembles those bits back to an object. This vulnerability occurs in Java object serialization for network transport and object deserialization on the receiving side.
Many applications accept serialized objects from the network without performing input validation checks before deserializing it. Crafted serialized objects can therefore lead to execution of arbitrary attacker code.
Although the problem itself is in the serialization and deserialization functionality of the Java programming language, the ACC library is known to be affected by this vulnerability. Any application or application framework could be vulnerable if it uses the ACC library and deserializes arbitrary, user-supplied Java serialized data.
Additional details about the vulnerability are available at the following links:
Cisco will release software updates that address this vulnerability. There are no workarounds that address this vulnerability.
This advisory is available at the following link:
Security Impact Rating: High