Bitcoin Forum
May 06, 2024, 08:50:19 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Topl on Developing a Scala Blockchain  (Read 478 times)
mattkindy (OP)
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile WWW
June 07, 2017, 05: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!
1715028619
Hero Member
*
Offline Offline

Posts: 1715028619

View Profile Personal Message (Offline)

Ignore
1715028619
Reply with quote  #2

1715028619
Report to moderator
1715028619
Hero Member
*
Offline Offline

Posts: 1715028619

View Profile Personal Message (Offline)

Ignore
1715028619
Reply with quote  #2

1715028619
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715028619
Hero Member
*
Offline Offline

Posts: 1715028619

View Profile Personal Message (Offline)

Ignore
1715028619
Reply with quote  #2

1715028619
Report to moderator
nativehasher
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
June 08, 2017, 04:14:14 AM
 #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?

golang, node.js and C++ developer.
BTC: 1NativecFuCN68n1rmHabkXRZnwuxpoJ4f
mattkindy (OP)
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile WWW
June 08, 2017, 04:03:15 PM
 #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!
nativehasher
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
June 09, 2017, 09: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.

golang, node.js and C++ developer.
BTC: 1NativecFuCN68n1rmHabkXRZnwuxpoJ4f
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!