What would I do differently if I were to create a new sidechain for Hive?

in #sidechain4 years ago
  • I would use TypeScript (I love Javascript but TypeScript definitely fits the job better) or Rust

  • I would not launch it without a consensus mechanism

  • I would make Hive the main "utility" token of the sidechain

  • I would make the whole Hive pegging mechanism trustless (multi sig?)

  • I would build the account history plugin directly in the main software (no separate tooling)

  • I would build a validation mechanism that would help detecting invalid transactions before broadcasting them

  • I would make it token oriented rather than contract oriented (that would make the whole codebase cleaner and more performant)

  • I would find a way to incentivize people to run nodes (DEX fees? other fees?)

  • I would build a REST API instead of a JSON RPC API

What would you do if you were able to make your own sidechain?
Sort:  

Speaking of the last one, I just watched a conference on gRPC that sounds interesting. I agree for Typescript 😉 and about the incentive it need to be a good balance so that it's not disproportionate to users or between nodes owners.

How would you make the pegging mechanism trustless?

I guess it depends on how we define "trustless", is using X signatures to validate a transfer via a p2p network "trustless" enough? I would say yes as it's kind of what blockchain technologies "use", now, it won't be as trustless as the Hive "null" account, but still better than what we did with the Hive/Steem pegged tokens (although this can already be done with Steem-Engine/Hive-Engine by updating the software).

we need a new, self-regulating SBD
more like DAI

Can you give an example of how this would work? I would be very interested in a more trustless way to handle pegged tokens (in addition to many of the other things you mention in the post).

and what do u suggest to provide feature - Currency for Enemies. As of now both hive and steem have failed on that front.