Make the blockchain visualization easier to interpret about plutus HOT 14 CLOSED

Time to write our own graph layout library? ;)

from plutus.

I generally agree and I think that for contracts the actual value of an output is maybe not important enough to justify the screen space that we are currently using to display it. My favoured visualisation at the moment looks like the graphs in #428 which make it easy to track what is happening at specific addresses.

Not sure if we can - our transaction model doesn't support that kind of metadata.

We could change the emulator to return printf output for successful transactions as well, not just for failed ones. Then we could use the traces to change the graph, for example only showing outputs that contain a keyword, or give a group of outputs a special colour.

from plutus.

The graphs in #428 make sense, but I think, the first step would be a description of how we would layout an arbitrary UTxO graph, to see how complicated it will be to implement a layout algorithm for it. Could you have a go at that @j-mueller?

from plutus.

@j-mueller wrote,

We could change the emulator to return printf output for successful transactions as well, not just for failed ones. Then we could use the traces to change the graph, for example only showing outputs that contain a keyword, or give a group of outputs a special colour.

Yes, I definitely like that idea.

from plutus.

Could you have a go at that @j-mueller?

Yes I'll think about it

from plutus.

to see how complicated it will be to implement a layout algorithm for it

Have you seen this: https://charticulator.com/? They use a constraint solver (Z3) to render the layouts.

I was playing around with rendering bar charts etc. using Z3 over Christmas and it works quite well. The nice thing about this is that you don't need a new layout algorithm for a new type of chart. You just say "the distance between these two things should be the greater than X" and so on.

I think we could use that approach as well, there is a Z3 binary available in webassembly. We only need to worry about specific algorithms if it turns out to be too slow.

from plutus.

Huh, I've wrestled with graph layouts before, but this is the first time I've seen the constraint-solver approach!

Worth noting as well that we're laying out a DAG, not a general graph. And we also potentially want to try and line up transactions in the same slot.

from plutus.

And we might be able to get away with doing most of the layout on the server, in which case we don't need Z3 on the client.

from plutus.

Yeah I never thought of it before reading the Charticulator paper but it's a really great idea. You can align things in the constraint solver easily by using the same variable in different places.

I'll work out an example for the UTXO graph later when I'm done with the tutorial. But the data structure I used looked like this:

data Glyph a = 
    Rectangle { x :: a, y :: a, width :: a, height :: a }
    | Line { from :: (a, a), to :: (a, a) }
    -- | etc.

data Region a = Region { left :: a, right :: a, top :: a, bottom :: a }

render :: MyData -> Region Z3Var -> ([Z3Constraint], [Glyph Z3Var])

then you render all the items, collect the constraints, solve them, and run something like lookup :: Z3Model -> Z3Var -> Maybe Double on all the coordinates. Then you just need to render the Glyph Doubles into the DOM.

You can divide the layout into smaller pieces with

-- split a region horizontally (creating two columns)
splitH :: Region Z3Var -> ([Z3Constraint], (Region Z3Var, Region Z3Var))

and so forth.

from plutus.

https://hackage.haskell.org/package/lp-diagrams

from plutus.

https://hackage.haskell.org/package/lp-diagrams

@j-mueller Have you had a look at it? Is it any good?

from plutus.

And we might be able to get away with doing most of the layout on the server, in which case we don't need Z3 on the client.

Well, there is a trade off here. On the one hand, doing the layout on the server keeps the complexity in the backend code. On the other hand, layout is sensitive to the available view area. In other words, we could do a better job with the layout if it was adapting to the size and shape of the browser window — that's what a nice UI would do.

from plutus.

@krisajenkins What are we going to do with this ticket? We decided to do some work on the visualisation by the summit, and then, revisit after the Summit. I think, we did everything for the former. Should we have a new ticket for the latter?

from plutus.

It is much better now! Let's use new tickets for more stuff.

from plutus.