Blockchain for Software Engineering

Concepts

Blockchain-based Software Engineering

Blockchain-based Software Engineering (BBSE) concept explores how blockchain technologies could revolutionize Software Engineering ¹.

Implications of BBSE

Professionalization

In SE, there exist many micro-to-small tasks. These are not per se difficult to execute, but require human diligence, e.g., to maintain packages, or CPU power, e.g., to execute builds. Like other distributions, Debian uses a fixed pool of mostly voluntary maintainers to manage packages. This noble principle of OSS, unfortunately, leads to a significant amount of peripheral packages being outdated because of inactive maintainers.

The reward for taking part in this transpar-ent and open process comes in the form of a small payment, both as a transaction fee and bounty. The market could reward urgent updates or builds in BCI with a higher bounty. ¹

Improved Quality

packages often break in different integration environments than what the maintainer has available to them. In a distributed system where a transaction gets verified by others, such as BAPT or BCI, the quality of releases or builds could improve due to a greater diversity in testers and equipment available to them. ¹

Trust

With Blockchain technology, we can replace a centralized system—be it a personal trust network or a techni- cal system such as Travis CI or GitHub—with a decentralized system verifiable by everyone. Moreover, a distributed system promises higher availability and resilience to partial outages. ¹

Potential Angles of BBSE

Continuous Integration

More than half of all projects doing CI on GitHub, do it with Travis CI

Travis CI provides a build environment for developers to test and deploy their code changes.

Travis CI internally does this by renting computing power from AWS.

Moreover, Travis provides a historic view of previously executed builds, a log that lends itself to a blockchain application.

Idea: Blockchain-based CI System (BCI):

1. Developers enter a build and its reward price in the mempool
2. The build is broadcasted to the BCI network
3. Interested workers exeucte the build
4. Interested workers report the outcome of the build to each other.
5. Workers find consenus (e.g., pass), and then add the build to the blockchain

Reason of BCI:

• Avoid the disruption due to outage of monolithic CI systems
• Open up the market so that everyone can partake and earn money with otherwise idling resources. It means that the economic rules of supply and demand regulate the build prices, not a single company.
• Maintain a persistent access to the history of builds.

Open questions:

• How to store build logs? The log might outgrow the 150GB ledger of Bitcoin very soon. The solution might be relying on lightweight node, heavy compression, storing information off-chain, or relying on eixsting BC-based file share solutions.
• How to resolve non-deterministic builds?
• How to guarantee the proof-of-work? Can we use hardware features like Intel's SGX?
• How to enable secrets? Travis CI allows the definition of private environment variables containing, such as deployment keys. How can we support them in a transparent BCI?

Source: ¹

Blockchain-based Package Manager

Motivation:

npm used to do essentially no vetting of the quality of new releases. This was painstakingly obvious in the left-pad incident, in which an Open-Source Software (OSS) developer who turned malicious caused great disturbance among the community by removing a trivial package on which thousands of other npm packages relied [20].

Limited measures to avoid such ripple effects of breaking releases already exist. For example, Debian uses a trust network that relies on personal connections. With their signature, Debian maintainers verify that they have done proper integration testing of a package.

Even so, this 1) cannot prevent random malicious actions, 2) puts a lot of work on few shoulders, 3) does not prevent package breakages,6 and, 4) implies that testing is limited to what a package maintainer can do.

Idea: Blockchain-based Package Repository (BAPT). This framework encapsulates a verifiable, community-driven regression test framework for package repositories.

• Every participant in BAPT can pick a new release candidate from the mempool, verifies that the release works as intended and does not break compatibility with downstream clinets.

Open question:

• How do we find consensus on what a "good release" is? Majority vote is not suitable for bugs that only appear in some environments. On the other hand, a veto-based consensus means that one malicious attacker could prevent a release.
• How do we test packages? Should we rely on manual testing like Debian does? What is the proof-of-work then?
• How to ensure all packages are included in the verification?

Sources: ¹