We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Embracing Language Servers for Blockchain Development

00:00

Formal Metadata

Title
Embracing Language Servers for Blockchain Development
Title of Series
Number of Parts
561
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
In this session I will demonstrate how we implemented a language server for the Solidity language, the language for smart contract development on the Ethereum blockchain. The language development is based on Eclipse Xtext, which implements the Language Server Protocol (LSP). By doing so, we were able to deliver Solidity tooling for multiple IDEs at once. I will show the Solidity integration for Eclipse, VSCode and Theia, and give some understanding about the LSP. Further I will show the development of smart contracts with the means of statemachines with the integration of Solidity into the Yakindu Statechart Tools.
10
58
80
111
137
Thumbnail
15:21
159
Thumbnail
18:51
168
Thumbnail
26:18
213
221
Thumbnail
15:22
234
Thumbnail
49:51
248
Thumbnail
23:06
256
268
283
Thumbnail
28:38
313
Thumbnail
1:00:10
318
Thumbnail
21:35
343
345
Thumbnail
36:13
353
Thumbnail
18:44
369
370
373
Thumbnail
44:37
396
Thumbnail
28:21
413
Thumbnail
16:24
439
455
Thumbnail
25:10
529
Thumbnail
15:36
535
Thumbnail
28:04
552
Programming languageServer (computing)ChainProgramming languageServer (computing)PasswordSoftware developerComputer animation
Maxima and minimaSineOpen sourceEnterprise architectureProgramming languageBuildingSoftware developerWordMetropolitan area networkBitDesign by contractChainComputing platformComputer animation
Rule of inferenceCodeComputerChainCodeDesign by contractCondition numberContext awarenessComputer animation
Computer programPlastikkarteIntegrated development environmentProgramming languageMultiplicationSolid geometryBlock (periodic table)Normal (geometry)Virtual machineDesign by contractSound effectMobile appArmCartesian coordinate systemError messageSocial classMathematical analysisFunctional programmingMusical ensembleComputer programmingPhysical systemDatabase transactionVideo gameSheaf (mathematics)BitWritingIntrusion detection systemConnected spaceLengthWordJava appletWeb 2.0Moment (mathematics)InternetworkingElement (mathematics)Complete metric spaceGoodness of fitCodeContent (media)Integrated development environmentInheritance (object-oriented programming)Extension (kinesiology)CASE <Informatik>TheoremSoftware bugPersonal digital assistant
Inclusion mapModal logicExecution unitComa BerenicesRange (statistics)Maxima and minimaProcess (computing)Hill differential equationWechselseitige InformationProgramming languageAuthoring systemSolid geometryServer (computing)Revision controlFunctional programmingCodeFluid staticsInformationDemo (music)Type theoryStatement (computer science)CompilerVideo gamePersonal digital assistantComputer animation
Server (computing)Programming languageIntelDisintegrationIntrusion detection systemVisual systemStandard deviationRemote procedure callCommunications protocolIntegrated development environmentClient (computing)Programming languageServer (computing)Communications protocolDesign by contractError messageClient (computing)Internet service providerMessage passingText editorFinite-state machineSoftware developerIntegrated development environmentSolid geometryCodeComputing platformComputer fileMathematicsVisualization (computer graphics)Personal digital assistantContent (media)Arithmetic progressionState of matterSound effectSpacetimeNumberType theoryScripting languageImplementationArmWordLink (knot theory)Intrusion detection systemWeb applicationMetropolitan area networkComputer animation
Keyboard shortcutJava appletClient (computing)Server (computing)Programming languageRule of inferenceConvex hullPlanar graphMenu (computing)Duality (mathematics)Execution unitVacuumHill differential equationComa BerenicesServer (computing)CodeProgramming languageSolid geometryCommunications protocolLibrary (computing)Formal grammarProblemorientierte ProgrammierspracheMessage passingRule of inferenceParsingIndependence (probability theory)Computer programmingProjective planeINTEGRALForm (programming)Integrated development environmentJava appletBuildingBitImplementationText editorCuboidView (database)Abstract syntaxComplete metric spaceLine (geometry)Computer fontClient (computing)Software frameworkExtension (kinesiology)Variety (linguistics)AdditionTunisElement (mathematics)Frame problemArmWordMiniDiscComputer animation
Maxima and minimaServer (computing)Programming languageComputer fileCartesian coordinate systemCodeExtension (kinesiology)Latent heatArmJava appletINTEGRALWeb browserWritingWeb 2.0Visualization (computer graphics)Text editorIntegrated development environmentComputer animation
Programming languageSolid geometryMoment (mathematics)Design by contractOrder (biology)Server (computing)Intrusion detection systemIntegrated development environmentCommunications protocolArithmetic meanComputing platformComputer animation
Programming languageServer (computing)Software frameworkSoftware developerClient (computing)Virtual machineFlow separationProcess (computing)Solid geometryFile systemCuboidScripting languageMoment (mathematics)WordVisualization (computer graphics)Interactive televisionDifferent (Kate Ryan album)Information privacyComputer fileExpert systemArmComputer animation
Computer animation
Transcript: English(auto-generated)
Thanks for joining my session. It's called Embracing Language Service for Blockchain Development. I try to put as many buzzwords as possible into the title. Let us look at what it's about.
Just one word to me. I'm Man Karsten. I'm working for a company in Germany called ITEMIS. And we're specialized on tool development. And that's actually what it's about today. Of course we want to talk a little bit about blockchains.
One blockchain platform is Ethereum. Did you hear about Ethereum already? Short words about that. Ethereum is a foundation who runs a platform
which allows you to execute smart contracts on a blockchain. So what is a smart contract? Actually a smart contract is a piece of code that you can deploy and execute on a blockchain. So somehow you have to develop these contracts.
So in these contracts you can say, okay, under which conditions do you transfer money from A to B? Or something like this. And you compile that code and deploy it to the blockchain and it's distributed over the blockchain and so it gets available for everyone and it's not infringable.
That's one of the benefits of blockchains. And to execute smart contracts you actually need to have some kind of money. It's called gas. And it has actually value. So you can buy gas and you have to use gas to execute transactions.
And what can you do with that for example? It depends on how many transactions are running at the moment on the blockchain. This determines the price of the gas. So when many people are running transactions at the same time
and try to get one transaction to one block, the gas price increases. And this leads to some strange effect. One of the most popular applications on the Ethereum blockchain
is selling and buying kittens. And when many people do this, these kittens get horribly expensive and I don't know who does this, but this was one of the use cases that increased the Ethereum gas price.
But the big question is how do we actually program something from the blockchain? That's what we need to talk a little bit about. And there are many programming languages out there but the most popular for Ethereum are called Solidity and Viper.
And I will talk now about this Solidity language. So what is Solidity? It's a complete programming language and with that programming language you can write contracts.
It's similar to a class concept. So you have values, you have functions that you can call and this programming language provides you literally everything that you know from the modern programming language like multiple inheritance and extension methods
and multiple return values and so literally I think everything is in this language. So you have a nice language to define contracts and this contract can be compiled to bytecode for the Ethereum virtual machine
and then you can deploy it to the virtual machine. And I'm a tool developer. I'm interested in providing good support for that language. There's actually an IDE provided by Ethereum which is called Remix.
And it is a web-based IDE. Let's see if I have an internet connection and I can show you live a little bit. So here it is.
So this is actually Solidity code. You can add this online and you can write simple programs and compile that code.
Actually this code is not compilable because there's some syntax error in it and this is marked here. But this is not really a good IDE. For example, this is really annoying here
and when I press, for example, Content Assist I literally see every keyword, every word that is in the program and not what makes sense here. I do not see documentation, other documentation like Java docs we are used to
or I cannot cross reference to elements that are defined somewhere else. All these things that we are used from modern IDEs is not available.
So, coming back. We have a complex language but the tooling is really crappy. And the problem is if you make errors here in contracts
then you can really lose money. There was one bug in 2017 where someone by accident called a suicide method on the contract which led to the fact that millions of dollars were locked in the blockchain
and just lost. So, it's really important that you know what your program is there and so you should see if there are errors in there if something doesn't make sense maybe do some decent analysis
and what you actually know from normal programming languages. So, what we can really do about that and this is what I want actually to talk about is a tool that we created the Yakinu Solidity tools
and in this tool we implemented the Solidity language and providing a language server. What this means, I'm telling you now about that. So, coming back to a small demo. Showing this live.
So, we see here, again, Solidity code and you see for example
here at the very beginning this is one thing that Solidity is the first statement Apacma which compiler version should be used and maybe it's not the latest one. And here we get immediately a proposal okay, you should maybe upgrade to that. You can use the quick fix here
and immediately change that. You can have content assist for example, if I press here then it only gets proposed what makes sense here to enter
or here, which functions can I call. So, we have static information about types and all what you use from one of the languages.
We take this now a step further. This is a work in progress. We are also building a tool which is called the Yakinu state chart tools and actually you can think about a contract like a state machine. So, you can model this now visually
and from that state machines we just cross-compile to Solidity code and then deploy that to a blockchain. And this can also be simulated. So, you can simulate what effect does it have if you transfer some money or whatever.
Yeah, but this is Eclipse space. And some people do not like Eclipse. I actually love Eclipse. I use it every day. But I totally understand that there are other editors outside there
and you may want to use the language not only in Eclipse but maybe for different platforms. And actually we provide the Solidity language already on four editors. Besides Eclipse, we also support Eclipse here.
I will show you that in a minute. It's a web-based editor. Visual Studio Code and ATEM. And more to come. How do we achieve this? And here we come to the language service. What is a language server? We have typically a problem when we develop languages
that there are several IDEs out there and for each language and each IDE you have to implement tooling. And if you would implement this natively for each IDE
then the language provider has plenty to do. Actually, the language provider does not want to get bothered how it is integrated into a certain IDE. On the other side, the IDE or editor developers don't want to care about languages.
There are coming languages every day and they can't support everything. And the IDEs get blown up with all the toolings that support the languages here. And here comes something in
which is called the language server protocol. When Microsoft started developing Visual Studio Code they had exactly the same problem. They developed a new IDE based on a TypeScript and they needed language support for TypeScript and C Sharp and others.
And then they thought, OK, do we re-implement the wheel again? No, they said, OK, we can define a protocol which is too agnostic and which decouples the editor from the language. So the editor is just dumb and says,
OK, I'm opening that file and editing here something. I want to press Content Assist. What can you offer me? And the language server is doing the hard stuff then for the language. So the language server knows,
OK, you're currently adding this file and at that offset you want to show Content Assist. I can show these offers. And this was a good idea and there stepped some other IDE developers up
and implemented also this standard. And so all the IDE developers are now driving this standard together with Microsoft. And so you can now provide languages independently from the IDEs.
The language server protocol is based on a JSON RPC. So basically it's sending JSON messages from tool to the server and back. And it works roughly like that. You have the tool. The user clicks on document
and it says, OK, I want to open a document and tell the server here this file is open. Then you start editing and the tool sends text changes to the server. It knows, ah, you're entering this document. I'm entering a word.
And the server on the other side can also send messages back to the tool. Say, OK, what you entered is not really valid. We have the syntax error here and this is my message.
There's a broad number of clients nowadays available that support the language server protocol. And on the other side also a broad variety of languages. And this is ongoing work. But you can expect that all editors and IDEs
will support that protocol. Actually it does only cover the typical 80% of what you actually need for the tooling. And each tool has its own tweaks which cannot be covered by a common protocol.
But the normal things that you do is done in the protocol already. And you can also extend the protocol. But then the extension must be known both by the client and the server. QuickFix is such an example
which is only provided by the Eclipse IDE. And we provide implementation for QuickFixes and yeah, you can see that in Eclipse. The protocol is language independent but there exists a binding for Java.
So when you're programming any language which are based on or implemented in Java then it's good to start with this project LSP4j. It's a framework, it's a library that implements all the messages that the protocol defines.
And of course if you program a language server in a different language then you have to use a different library. We implemented that with Java and especially with a framework called Xtext. That's actually my work, what I'm daily doing.
I'm working on that project. And Xtext is a framework to develop languages. So when you want to implement programming languages or domain specific languages then this is the way to go. With Xtext you can describe very simple language
defined by a grammar, create all the implementation and you get all the editor integration out of the box. And also you can build language server with that. So I will now dig a little bit into the code
to give you an impression what's behind that to build a language server for Solidity. And this is our development environment. It's quite a bunch of projects that we have here
but there's one project that is most important which contains the language definition. And if you're known a little bit to language design then you know that you need some kind of grammar to describe the language.
It's closely to a BNF form but we mix concrete and abstract syntax. So we also see keywords that the language supports in the grammar.
What we do from this is generate a grammar for Antler. So behind our parser technology is Antler but this grammar is much simpler than the Antler grammar. And so here's the complete definition of Solidity language.
It's not that huge. Just four lines of code that you need for all the rules. And when you have defined that you typically run a code generator
and this is when X6 comes into play and generates the infrastructure for the tooling.
So what you get is the parser, you get syntax highlighting, you get cross-linking, so scoping is implemented. We have a nice outline view here so it can... where is it?
I think it's... ah, it's here. So you can directly navigate to elements. This is what you get for free when you use X6 for any language that you develop. And Solidity is just one example that we developed with that.
Now let's have a look at the language server. So we saw already that it's working in Eclipse. And now let's look at Theor. So this is now a browser IDE. You could deploy this on the web.
And you have the same things that you're used to from the Eclipse editor. So it proposes you what you can do here. It reports when you're writing something wrong. So whatever you need.
And the server behind that is the same in Eclipse, in Theor, in Atom, in Visual Studio. You develop the language once, create an application. It's actually a runnable Java application. Then you need to provide tool-specific integration.
For Eclipse you would need to write a small Eclipse plug-in which uses LSP4E for example. In Visual Studio Code you would write a VS Code extension which is an NPM package. Same for Theor.
And it depends on the tool, how it integrates the language server. Basically what it does is it describes this is my file extension and whenever you open the file extension start the language server and communicate with that. So this is the integration work. But the language server is just written once.
So let's wrap up. We have Ethereum, which is a platform to execute smart contracts.
To execute them you need money and gas. And to write such contracts you need a programming language and one of those is Solidity. With the language server protocol we are able now to develop one language and provide it to different IDEs.
Almost all of the IDEs support that at the moment. And we just implemented a Solidity language which was an existing language with means of xText and so we got a language server for Solidity.
And so we provide good tooling now for this programming language. OK. I'm already done. I'm open now for questions. Yes?
There may be some very important thing to talk about or maybe the question. What about privacy? Does it send a file? One important thing about language servers is the word server is misleading.
It's not that you run the language server somewhere on the server and the client is on a different machine. It's usually bound to the same machine. It's just separation of concerns. You have one process which is the client, the tool and the server on the same machine also on the same file system.
And it's even bound to the user. So it interacts with the user. Yes? Is it hard to add LSP support to xText?
The answer is no. It's actually quite easy. And it's already integrated so you don't have to care about that. So the framework xText integrates language server support through LSP4j and you just don't have to care about that.
So the only thing is that you have to build your language using Maven or Gradle and you can get this out of the box that you get build scripts that produce your language server for that.
Question behind? The question is do we have experience with integrating language server in IntelliJ? Yes, but not good ones.
It's actually at the moment that IntelliJ is lacking behind. There's some plug-in developed externally that provides language server support. But it works okayish.
The best LSP support you actually get at the moment is visual studio and eclipse.
Question was how is ethereum involved here? Was it our initiative to develop this language? Yes, it was our initiative because we started to work with ethereum
and then we saw okay, the tool sucks. You can't really work with that. And we are an expert in language development so we started with that. But the ethereum foundation is a foundation
that collects money from its members and also spreads money to users and we got a grant to work on Solidity tools. So they partially funded the development now.
Okay, then no more questions. Thank you very much for your attention.