dType and ChainLens by Loredana Cirstea

so hello oh I'm happy to be here to share with you our latest work and research on d-type and chain lands the type is by far the most intellectually and elegant project intellectually satisfying an elegant project that I have ever worked on because it embodies the values that I cherish the most which are transparency and unity and unity through folding the basic building blocks of software types so d-type is a decentralized type system the types goal is to standardize a common type description format stored on chain so available to everyone types themselves are stored on chain including custom types and this will allow a degree of interoperability that has not existed before so these are our motivations normative rules in computing must be open to everyone and an an unfortunate counter example to this is the floating-point arithmetic standard which is pay world and it it costs 100 dollars to access it and webassembly which is supposed to be an open standard and it is built to become the future binary language for software building blocks uses it anyone should be able to read the full open standard of such a system unity if we want to truly build the Babylon hour of software a convergence to generally agreed upon types must happen and the good side effect of having an unchanging standard is that you can always use it to verify that your software follows it closely and you can use that software in this case B type as a source of truth when when bugs arise so these are our motivations what is the philosophy on which D type is being built all types derive from the same Prima Materia this Prima Materia for D type is bit 1 and it is very real it is representable on the wire which means you can use the hardware as an etholon to mathematics as opposed to other type systems which use abstract ideas like not natural numbers but Ramon atheria can be variable and for example we are curious to see if the type will be flexible enough for a powder parallel piping system dependent on one qubit for D type font types are functions and functions are types specifically all functions with the same output of the same type represent that type and we should be able to travel from from the type to Prima Materia and this means its input is Prima Materia or derived from it typecasting rules must be defined in the type system so every type is generated and can be traced back to the initial untyped Prima Materia the type system should be flexible in terms of encoding and decoding on various hardware at least for 32 and 64-bit systems so is the type static or dynamic and you will see it is both in the sense that it comes in two flavors the type is nominative because types can have the same underlying structure but very different semantics in the sense that it you must not be able to add apples and oranges even though they are both unsigned integers but first our roots the top version one was based on c-like structs and it allowed us to start thinking about how such a system could be integrated in a theorem 2.0 and we advocated for having a special shard for the operating system components such as types which would effectively act as a global scope for all other shards and all the links to this can be found in the detail poster now d type version 2 is functional and it is built upon the knowledge that we gathered while building pipeline specifically the unchained pipeline graph interpreter that we now have life for testing all types are now based on functions so pipeline itself can be an editor for creating new types and the new D type engine is actually a graph interpreter for functions residing in the same contract and both compiled functions and runtime created functions in the form of graphs so I'm now introducing I shoot a fuel you'll plus extensions for using the type as a type system and pipeline as an interpreted language our target is compatibility with was with webassembly and with any aetherium vm therefore we chose you'll for tech stock and then we found about your class so our first step was to introduce our own memory struct in Yule plus with support for D type types to get a sense of what we need and what can be done and I'm keeping in contact with Nick Dotson from fuel labs who will talk about yield pass later today and I think it's their first talk after mine on how we can make Yule plus support extensions for various encoding and decoding formats the initial type bootstrap for the Yule plus extension was done with that definitions from a JSON file where types were defined based on other types and you can find this in my you'll + fork in the Taylor branch this allowed me to more easily extend your + to memory structs containing dynamic types and we used it to start developing the own chain taylor interpreted type system based on on our pipeline model so taylor is functional and comes in two flavors interpreted and compiled compiled where the yield + transpiler extension uses own chain b type data for encoding and decoding and pipeline can be used to compose types and in the future type definitions will be shadowed in multiple languages where a pipeline interpreter exists so presently the type can have support for any type of any encoding and the EVM is not restricted to only solidity types so what are the native Taylor functions type creation starts by using a suitable ativ functions that will be used recursively and most of them are pure functions like new identity config concat MapReduce curry but state mutating functions for type values and they pay function are part of a Taylor extension where logic can be built upon the same principles of interpreting graphs in my last article about Corrine I explained how the core of the mechanism works we currently use four byte signatures four types and all recursive calls go to execute internal executors internal tries to call execute native or execute curried depending on a success variable that each of them returns and all native functions that I previously showed you reside in executing native in a switch case statement virtual curried functions are handled by execute curried which retrieves the data from a pointer in memory and the pointer is also the curried function signature the interpreted flavor of tailor version 1 is significantly more complex than my article example and stored graphs four types are handled by the execute graph function and we also have support for named and sized types but a run of this system would not fit a slide and would require at least five minutes of explanation and if you know pipeline you know why the execute graph part can become very complex so these are links to my recent articles also found on medium on how recursive apply and Corrine works as a prerequisite talk prerequisite reading for this talk recursive apply is the engine of functional programming and we have implemented it along with Corrine in our own chaining interpreter so what types can be built with Taylor from bit one two numbers to erase tuples Union to n dimensional arrays and trees the types in both do not exist in solidity and D type is made to be compatible with third buffers and Seaborg we are working on type formulas to define a proper set of native functions and we currently have working implementation for implementations for bytes unsigned integers static arrays static and dimensional arrays and Union and these are based on a typed encoding format this is one of the encoding formats that we are working on a touch format where values always come with their type and it can act as an intermediate representation for other types of encoding so this enables smart contracts to do runtime type checking and values stored under this format expose their type directly in the byte code making robot code analysis more rich in information and at the moment we are using a four byte signature for types and the base types have a hard-coded signature format where the last three bytes represent the size so currently a topple which you can see on the right starting with EE also contains the additive sum of component sizes for ease abuse these are the current data structures that we are working with each type definition is an ordered array of steps and each step contains the signature of a type which is a function and an array of input indexes these input indexes are the indexes of the input arguments from the set of all graph local variables that are produced while running the graph and on the right you can see our current n dimensional array definition using the new reduced config yet type signature curry and concatenated functions this is an example of a union type definition it only needs a selector index for the component type and the native select function the selector runtime value is expected to be at position 0 in the actual data so when you define a type that can have sizes for example you int you don't need to define every size type so you don't need to store another definition for you in 256 so you can think about the abstract type you went as a partially applied function and we also have support for named types as I said before you shouldn't be able to add apples and oranges nor the various crc 20 tokens together so now for a short demo this is a modified version of the you'll pass extension for remyxx and this is the tailor graph interpreter contract which I will be deploying and now we are going to insert the definition for the UN type and then the definition for the simple array type and now we are going to call the function for creating a new array so this is the signature for the execute function which is the main entry point in the program this is the signature for simple arrays it starts with four four four it doesn't have a size because it's the abstract type all the inputs and outputs are wrapped in tuples so ee ee is a tuple of size three and the next three values will be the additive lengths of the components of the tupple so our first value of our first argument is a type two value and the value is essentially this which is the signature of the abstract you wind type and itself is a bytes value so that's why we have bytes of type of size four here so we are effectively effectively we want an array with you and items now the second argument is this which is 32 so we want an a an array of you wind sized 32 elements which is equivalent to you in 256 and the last argument is 4 which is the length of the array so we call this and we get again another tuple with one element and the type value is this one so this is the signature for an array with and for which contains you wind up size 32 so 256 in solidity and the next value the next is the actual value which is initialized with 0 I don't have time to show more examples or examples of casting so I will go back to the presentation so to summarize I have talked about the interpreted flavor of Taylor I'm not sure if you are seeing the correct slide because I'm not we are seeing a further research there was a nice light with a diagram here but I don't seem to be able to show it maybe I'll show it later so to summarize I have talked about the interpreted flavor of Taylor the types created on chain can be used for the transpired version so Taylor as a Yule plus extension providing type definitions encoding and decoding rules and type checking further research for the near future is an efficient set of native functions optimizing the steps needed for building and casting types and bootstrapping the Taylor interpreter so it uses Taylor produced types and parametrizing based based on VM slot size Taylor's native sizes and Prima Materia this was the diagram that I showed you earlier so the type and pipeline go hand-in-hand VI provides a minimal set of typeless functions maintains a table of signatures provides pipeline with input and output choices being able to parse the input enough pointers and pipeline helped us turn D type into a combination of function into combinations of functions ran by an intra contract pipeline interpreter and will also provide inter contract type processing and this is how white one can be represented it receives bit 1 as input which is repeated a given number of times in this case 8 but I okay this was the diagram I'm not sure if you saw it earlier and now for the N dimensional array example the end I dimensional array can have n dimensions where n is larger than 2 and on the right you can see a representation of an empty array with 3 dimensions the first 3 4 byte slots are the type IDs for each sub array which with its own dimension and the fourth fourth white slot is the UN 32 type ID and then the values in this case initialize with the zeros so I showed you the type tailor and pipeline what is the purpose of lens lens is a browsable and searchable cash for unchain types and it will provide data for editor tools or input for tools like pipeline and anyone will be able to run it at home because the main they are is aunty but as we well know most people prefer trusted setups over running their own and I think the next level in providing good come on good software data is a system of decentralized governance where companies or individuals join database clusters so having one company control all of the source code is begging for problems and I for one do not want the next wise and package manager to follow suit our current version of chain lens was the right form our work on the pipeline contract finder where we needed the api's have already deployed contracts and if you do not know how to use chain lens with pipeline check out my YouTube videos but chain lens only has two types contracts and functions the lens will have multiple types and we have around 40,000 contracts waiting to be published under the centralized database with better so how would be lens look like and I have a small demo here which will run on the rock eruption so this is how the current chain lens looks like it has contracts you can search through them browse them and functions and you can interact with those contracts and functions and then you can export them to other tools so now let's see what types we already have inserted in the ruction deployed Taylor contract so we have here some types and I will insert another named type which will be a youant of size 4 which we'll name scarce token and while we are waiting for the Rakatan transaction to finalize i will show you another thing that we have which is a prototype of a typed database on chain so for type new one I'll click on this button and we'll see the values that are stored now under type e1 in in this small database so we have two value 6 and 7 and another value under type YouTube and what we can do is select some of these values and then we can export them and apply other tools on on these values so while we are waiting for the transaction to finalize I'm going to tell you why we are building the type lens and pipeline in parallel because the process is slower but it allows us to learn from each of them and it influences how we build them individually so the D type lens pipeline flow is as follows pipeline handles pure graphs from pure functions provided by lens and it receives input from D type through lens and the result is a state transformation graph applied to insert or modify the output which is ad type value and now we can see the new type that we inserted here and we can add other values to it but I will return to my presentation now so if you will port your project to D type you will be able to generate types from the type in multiple languages do own chain type checking and cross-checking and I don't think you can see the correct side okay this is a call to arms for unifying types across languages and I don't think the blockchain revolution has ended and we are betting it will restart on other vectors than money so defining types on chain guarantees that boxing programmers will be part of the next octave revolution which will come I do block chain as a citadel for common resources and computable standards and many may say that this is very hard to actually achieve which is true but I cannot think of a higher scope and goal than this one and this is why I donated my time to this cause so after our work for more than a year on b-type we are in the position to launch this hypothesis if I the centralized blockchain based OS will ever exist it will contain its type definitions in its own chain boot sequence and we wish you success in building