We use cookies and other tracking technologies to improve your browsing experience on our site, analyze site traffic, and understand where our audience is coming from. To find out more, please read our privacy policy.

By choosing 'I Accept', you consent to our use of cookies and other tracking technologies.

We use cookies and other tracking technologies to improve your browsing experience on our site, analyze site traffic, and understand where our audience is coming from. To find out more, please read our privacy policy.

By choosing 'I Accept', you consent to our use of cookies and other tracking technologies. Less

We use cookies and other tracking technologies... More

Login or register
to apply for this job!

Login or register to start contributing with an article!

Login or register
to see more jobs from this company!

Login or register
to boost this post!

Show some love to the author of this blog by giving their post some rocket fuel 🚀.

Login or register to search for your ideal job!

Login or register to start working on this issue!

Engineers who find a new job through Blockchain Works average a 15% increase in salary 🚀

Blog hero image

Everyone Should Build Their Next Blockchain in Scala

Zihe Huang 15 December, 2017 (4 min read)

We talked about why we are not using Ethereum for our main chain in our last blog post. In this blog, I will expand on how we are using the Scorex 2 Framework, developed by IOHK. This is a name that may sound familiar because the Waves platform is also built on top of the original Scorex Framework. The decision to use Scorex 2 is based off these constraints for our project:

  1. The Topl Network needs to be public due to the nature of global capital markets.
  2. Investors seek privacy about their investment history. They also seek more information about their partnership with potential investment targets, prompting a need for a robust reputation/ranking system.
  3. The code base should be easy to learn and maintain for the community.

One possible answer to solve the privacy concerns would be Quorum. However, if we take a closer look at Quorum, its private transactions are stored in a separate database that is disconnected from the rest of the network, which means an un-associated third party never verifies this private transaction. This design makes perfect sense in a permissioned, aka private chain, where you can trust different accounts in the network, but it violates constraint #1.

We still have couple choices, we could fork Bitcoin, which has over 100K lines of C++ code, or Ethereum, which contains a quasi-Turing complete Ethereum Virtual Machine. Both options have unnecessary pieces we have little use of. It usually takes a long time for a new developer from the open-source community to start contributing meaningfully to the core of a project. Forking a code base with an onerous size builds an artificial barrier to entry and definitely hurts and process of bringing on new developers. That being said, the code base needs to be reasonable for new developers. Forking Bitcoin or Ethereum absolutely violates constraint #3.


Scorex 2 is a framework that meets all the constraints I listed above. It is tried and tested by Waves. It is written in Scala, an extremely powerful language. Using a complete and mature language ensures us to be able to add new things such as zk-SNARKs, its associated compilers, and ring signatures. Most importantly, Scorex 2 only has about 4K lines of code, making it easy to learn once you understand the general concepts that are abstracted by the framework. Scorex 2 now has 4 example blockchain clients, making it even easier to modify and swap out different blockchain components, including consensus algorithms, blockchain history, and transactions. It was exactly what we needed — a modular blockchain that is easy to learn and customize for our demands now and in the future. Scorex 2 is prescriptive in modularity, but not inhibitive in design, allowing massive amount of code reuse. Networking, database snapshots and consensus are built in with Scorex, saving a huge number of headaches for our development.


A great example of this modularity is Scorex’s atomic data storage unit called a box. A box is similar to an unspent output in Bitcoin, or you can think of it as a key-value pair. You need to include these boxes in transactions along with your signatures in order for the transactions to be considered valid. In a portion of our code, we have different transactions that take different types of boxes, each with Long as their value. Thus, it makes sense to abstract the common elements.


abstract class BifrostPublic25519NoncedBox(override val proposition: PublicKey25519Proposition,
                                      override val nonce: Long,
                                      override val value: Long
                                      ) extends BifrostBox(proposition, nonce, value) {

  lazy val id: Array[Byte] = PublicKeyNoncedBox.idFromBox(proposition, nonce)

  lazy val typeOfBox: String = "BifrostPublic25519NoncedBox"

  lazy val json: Json = Map(
    "id" -> Base58.encode(id).asJson,
    "type" -> typeOfBox.asJson,
    "proposition" -> Base58.encode(proposition.pubKeyBytes).asJson,
    "value" -> value.asJson,
    "nonce" -> nonce.asJson
  ).asJson

}

We define this nonced box to be a child of BifrostBox, which is a child of Box from Scorex 2. Since reusing code in Scala is so easy, implementing specific boxes is simply inheriting our BifrostPublic25519NoncedBox.


case class ArbitBox(override val proposition: PublicKey25519Proposition,
                   override val nonce: Long,
                   override val value: Long) extends BifrostPublic25519NoncedBox(proposition, nonce, value) {
  override lazy val typeOfBox: String = "Arbit"
}

case class PolyBox(override val proposition: PublicKey25519Proposition,
                   override val nonce: Long,
                   override val value: Long) extends BifrostPublic25519NoncedBox(proposition, nonce, value) {
  override lazy val typeOfBox: String = "Poly"
}

In addition to all this, I haven’t even mentioned all the benefits of using Scala yet, have I? A JVM language like Scala allows blockchains to easily run on pretty much any general purpose computing device you can think of, including phones and micro-computers. Being able to export a blockchain client and run it on a phone is a huge plus. You can also develop Scala in your favorite IDE. When there is a weird bug that is not obvious, debug it using the debugger and watch any expressions of your choice.


I hope that this is a good overview of how we are using Scorex 2 and why we chose Scorex over other alternatives. The decision of building on Scorex 2 is an engineering decision. With all this being said, Topl’s blockchain will be connected to Ethereum and other platforms in the spirit of avoiding isolated and siloed systems. I hope the community realizes the benefits of building on top of each other and leveraging each chain’s benefits instead of fixating on their shortcomings and dismissing them outright.

To learn more about our project, you can visit us at topl.co or check out our Github.

Thanks to Zihe Haung for contributing this post, the original source can be found here

Originally published on medium.com