Author

Topic: Topl on Developing a Scala Blockchain (Read 481 times)

member
Activity: 73
Merit: 10
June 09, 2017, 04:50:58 AM
#4
Scorex under the hood uses Akka actor references for message passing between modules meaning there's no static type checking for class properties that use ActorRef. What you can do then is, for example,

Code:
implicit lazy val settings = new ForgingSettings {
    override val settingsJSON: Map[String, circe.Json] = settingsFromFile(settingsFilename)
  }

val forger: ActorRef = actorSystem.actorOf(Props(classOf[Forger], settings, nodeViewHolderRef))

override val localInterface: ActorRef = actorSystem.actorOf(Props(classOf[BifrostLocalInterface], nodeViewHolderRef, forger, settings))

If you want to change consensus rules or whatnot, just reference different files. Alternatively, you can always do this in memory. For reference, a simple ForgingSettings might look like this:

Code:
trait ForgingSettings extends Settings with ForgingConstants {

  val InitialDifficulty = 15000000L
  val MinimumDifficulty = 100L

  lazy val offlineGeneration = settingsJSON.get("offlineGeneration").flatMap(_.asBoolean).getOrElse(false)

  lazy val posAttachmentSize = settingsJSON.get("posAttachmentSize").flatMap(_.asNumber).flatMap(_.toInt)
    .getOrElse(DefaulPtosAttachmentSize)

  val DefaulPtosAttachmentSize = 1024

  override def toString: String = (Map("BlockDelay" -> blockGenerationDelay.length.asJson) ++
    settingsJSON.map(s => s._1 -> s._2)).asJson.spaces2
}

(This is using io.circe for json parsing) You can generally just swap between different children of Settings for different consensus modules.

Scorex also has a testkit built in if you want to do discrete runs quickly between different settings. It would essentially be handled the same way as well.

Cheers!

Thanks a ton for the detailed response, it is very useful for me. Good luck for your project.
newbie
Activity: 4
Merit: 0
June 08, 2017, 11:03:15 AM
#3
Scorex under the hood uses Akka actor references for message passing between modules meaning there's no static type checking for class properties that use ActorRef. What you can do then is, for example,

Code:
implicit lazy val settings = new ForgingSettings {
    override val settingsJSON: Map[String, circe.Json] = settingsFromFile(settingsFilename)
  }

val forger: ActorRef = actorSystem.actorOf(Props(classOf[Forger], settings, nodeViewHolderRef))

override val localInterface: ActorRef = actorSystem.actorOf(Props(classOf[BifrostLocalInterface], nodeViewHolderRef, forger, settings))

If you want to change consensus rules or whatnot, just reference different files. Alternatively, you can always do this in memory. For reference, a simple ForgingSettings might look like this:

Code:
trait ForgingSettings extends Settings with ForgingConstants {

  val InitialDifficulty = 15000000L
  val MinimumDifficulty = 100L

  lazy val offlineGeneration = settingsJSON.get("offlineGeneration").flatMap(_.asBoolean).getOrElse(false)

  lazy val posAttachmentSize = settingsJSON.get("posAttachmentSize").flatMap(_.asNumber).flatMap(_.toInt)
    .getOrElse(DefaulPtosAttachmentSize)

  val DefaulPtosAttachmentSize = 1024

  override def toString: String = (Map("BlockDelay" -> blockGenerationDelay.length.asJson) ++
    settingsJSON.map(s => s._1 -> s._2)).asJson.spaces2
}

(This is using io.circe for json parsing) You can generally just swap between different children of Settings for different consensus modules.

Scorex also has a testkit built in if you want to do discrete runs quickly between different settings. It would essentially be handled the same way as well.

Cheers!
member
Activity: 73
Merit: 10
June 07, 2017, 11:14:14 PM
#2
Scorex 2 looks quite promising to me, and I plan to develop my prototype for a blockchain for IoT project using it.

I do have a question though, how do you simulate the consensus rules and vary various configuration/network parameters for different runs? Is there a tool/library you would recommend?
newbie
Activity: 4
Merit: 0
June 07, 2017, 12:02:14 PM
#1
Hey, everyone. Matt from Topl here. My colleague, Zihe, just put out a new post about engineering our blockchain in Scala and using Scorex 2 by IOHK. I think it's worth a read to get an idea of the type of development work we're doing. Would appreciate any feedback, questions, and other comments, of course!

Why Everyone Should Build Their Next Blockchain in Scala

We believe that one of the biggest advantages of using Scorex 2 is that it can (and should) begin to become a focal point for cryptocurrency component standardization (e.g., consensus modules, networking modules, etc.) which should reduce the friction associated with developing new blockchains and building towards an internet of blockchains (for those projects where, for example, a Dapp may not be an appropriate fit for various reasons). Let me know what you think!
Jump to: