Ouroboros for the Java Virtual Machine


#1

This is a question for the Cardano engineering people - is the information available publicly for Ouroboros good and stable enough to proceed and implement it in the JVM?

For anyone else - if you interested in participating in the work towards having Ouroboros in a JVM implementation contact me.

Best
Cristian (Cris) Malinescu
Toronto/Canada


#2

It will be implemented in Scala. Is this an independent project or are you with another crypto project? We could talk about it.


#3

This is an independent project.
I had the choice between Java/Scala/Kotlin and I settled for Kotlin - reasons follow.
Even if I love Scala and I find it the best alternative for the JVM ecosystem richness wise there are serious drawbacks to it and these are the ones who kept me away:

  • very long compilation times; as a developer this is very annoying and I hate to waste my time waiting after the
    compiler exactly like in the case of C++. There are do and don’t guidelines with regards to how to write Scala
    code and what contructs to stay away from however, nobody can enforce them in a heterogeneous team.
  • the amount of behind the scenes byte code generated by scalac - sugar code, is humongous due to need to
    convert Scala covered paradigms to the JVM supported constructs; this will put a lot of pressure on the
    memory and garbage collector. Of course this can be reduced following do and don’t guidelines however, I
    don’t find it feasible in a heterogeneous team.
  • to write robust and safe to concurrency issues code in Scala the only choice are actors or reactive streams;
    this mean introduction of 3rd party libraries with resulting consequences. Actors and reactive streams for
    Scala are known to boost a lot the support for big number of connections and backpressure however, I don’t
    find these as concerns for nodes meant to live in a P2P architecture, but only in enterprise scale datacenters
    or computing grids. This will solely result only in more pressure on memory and cpu due to garbage
    collection and extra cycles.
  • Scala ecosystem goes trough massive changes with the 1.13 and Dotty initiative. Practically the code written
    till now and the near future using 1.12 will need serious refactoring effort when these upgrades will happen.
    Or, you chose to stay stuck in the past and will find harder and harder to maintain and change the code
    efficiency due to consequences of using an older release.
    Despite all of these, I would chose Scala only if the amount of functional paradigms needed to be addressed
    is so big and possible only with Scala to code in a concise, readable and maintainable way. Personally, I don’t
    find it so, I think that Kotlin support for functional constructs should be good enough.
    Other Kotlin advantages - fast compilation, close to scalac; tooling - this is big one for me because I love to
    save every second here and there, they sum up at the end. Language native support for coroutines as of 1.2 -
    which I use, makes obsolete the need for 3rd party libraries. Lower amount of do and don’t guidelines to track
    in the code if high code quality is a main factor.
    The only advantage here for Scala would be less code however, I don’t think the delta would offer a real
    cost/benefit ratio in Scala’s advantage.
    Scalability - network & storage, and transaction completion/recording times are the big chalenges for the
    Blockchain architecture and in a heterogeneous, WAN deployment of potentially many millions of nodes every
    damn single cycle and nanosecond matters, we face this challenges for real only now with the dawn of the
    Blockchain as the society’s backbone and I think here Scala’s need for lots of sugar constructs puting
    pressure on cpu additionally to the network i/o is not desirable. Like the real life proof of the kitty madness
    with Ethereum - it took just a real application to reveal the scalability problems people where triggering alerts
    for long.
    I’ll be glad to help you if you are more advanced with the implementation however, I need to see strong
    arguments why would I settle for Scala and not Kotlin.
    Best

#5

Had to remove that last comment.

Ok, we will support you in anyway we can.


#6

Thank you. I was looking into the organization repositories https://github.com/input-output-hk and couldn’t spot the JVM/Scala implementation. Is it publicly available?


#7

@io_jeremy Will IOHK be leading the development for the Scala implementation, or community driven?


#8

Sorry about that, it will be internal. I didn’t realize.


Is Haskell an impediment to uptake?
#9

That’s actually great.

Given Haskell has a smaller community comparing to JVM, it’s good to have a Scala implementation from internal as a reference for other future community based project.

I am assuming the project won’t be a focus until after Byron is released?


#10

We are currently working on Ouroboros Praos actually. This is an upgrade to make the protocol even more resilient to real word threats, not just the theoretical ones POW proponents attack POS systems for. We are also bringing in some more people to vet and improve our formal verification process.


#11

@io_jeremy is a repository publicly available?


#12

not at this time


#13

@io_jeremy is the Scala implementation going to be compatible with these interfaces?
https://cardanodocs.com/technical/explorer/api/
https://cardanodocs.com/technical/wallet/api/


#14

I don’t believe so.


#15

@io_jeremy Ok, is the interface documentation publicly available?


#16

#17

@io_jeremy I’m confused now. Few entries ahead you mentioned that your in-house JVM API implementation is not going to be compatible with the public specs, now, which of these should I take at face value?


#18

Maybe I am getting confused between threads. Or I am not following your questions.

We will not have a Scala version of Cardano. So we will not have a JVM API implementation.


#19

@io_jeremy @maki.mukai I’m completely baffled now. For the last almost 24h I lived with the understanding that you are working at a JVM version of the Ouroboros - this is what the first entries in the thread say, so, is it so or not?! Can you folks do a better work at helping the community building solutions around your platform? Community traction would help drive your work towards success also - that’s what made Linux and other members of the OS community successful. Can you add to the portal a community dedicated section where people wanting to build solutions - like partnership, around the platform can just proceed and do-it?


#20

I think I see the issue. I removed a post but did not retract the first comment. Apologies.

The Scala implementation of Ouroboros will not be public.

Yes, this forum opened around a week ago, and IOHK does not have anyone right now to manage an open-source strategy.

What is the best way we can support this now? I see ‘Technical discussion’ has been taken over by people asking for software help. Perhaps I should ask them to add a Developer category.


#21

@io_jeremy - that would be a good idea. How about keeping on track with the public interfaces - so let’s reformulate, if for example, me, I implement an open source version of the publicly available documentation, what it would take to my node to connect to the Cardano network interface wise, if my node would implement the public swagger specs - is that all what it will ensure compatibility? Look at the Ethereum ecosystem - not a big fan of their architecture and technological stack, that’s the reason my analysis led me to Cardano, they have a variety of client node implementations just because all follow same interface specs, is this something posible to envision for Cardano also, an ecosystem consisting from multiple node implementations all possible to connect to the Cardano network just by following the public interface specs? When I seen REST in your public docs that was my perception, that’s what REST microservices are meant for, right?