LUKSO: the project re-imagining the entire game. We got the opportunity to talk more in-depth with Jean Cavallera, Smart Contract Engineer at LUKSO about what they’re building, the ups, the downs, security, and everything in between. Let’s get into it!
What are you building, and what sets it apart in the space?
We are building a lot of things at LUKSO. LUKSO is a layer-1 EVM blockchain with new tools and standards. From standard specifications to smart contracts implementations, tools for developers, and a browser extension for end users. What sets it apart in the space from other projects is that we are covering solutions for the whole spectrum, from the developer experience to the end user. Most of our development is focused on revolutionizing the user experience with blockchain technology to be able to truly take it mainstream and overcome the problems faced with blockchain technology today, which is what drives our requirements to create these new building blocks for mainstream use cases in the new creative economies.
What’s your vision for your project? What are you building towards in the longer view?
From my perspective, the vision of LUKSO is really to take away all the complexity behind blockchain technology. This includes private keys, smart contracts, and interfaces. We are trying to build products and tools that take all of this complexity away so that it is easier for the developer and also users. For example, developers building on LUKSO don’t need to understand the underlying mechanism of the ERC725Y storage and the LSP2 encoding schema, our tools like erc725.js and lsp-factory.js do that for them under the hood, without them needing to understand these complex details. The tools aim to do all the heavy lifting for you so that you can focus on your project and building your product.
For the user, it’s really to offer a new way to interact with the blockchain. Universal Profiles and all the other LSP standards (the LSP9 Vault, the LSP6 Key Manager, etc…) exist to fill this gap we have seen with complex user experiences. LUKSO’s standards are there so that people can then use the blockchain in a meaningful manner (create a vault where you store assets for the future for your kids, set up some form of access control for third parties, to allow them what they can do and read on your account, etc…). With our solutions, blockchain can ultimately be used seamlessly by everyone without even realizing they are interacting with blockchain technology, and this allows for next-generation applications and experiences to evolve.
What’s been the biggest challenge throughout the entire process?
Security! It has definitely been the most challenging part. It’s always in our minds when we are building the standards and the smart contracts. We want to create a great developer and user experience, without having to compromise security at any point.
Another challenge has been experimenting with the standards we are building through various use cases. It’s often to explore the question “how are people going to use all the things we are building?”. You just don’t know what people will come up with! We are looking forward to seeing the ecosystem evolve.
Talk more to us about ‘identification, virtualization, tokenization’. What does this mean in LUKSO’s ecosystem? How did your team build a culture of security into a project that’s so multi-faceted, did you have any security concerns?
Yes, we always have had security concerns, but we found ways to ensure that security is a big part of our process. For instance, we have a lot of automation in place that checks for security and vulnerabilities in our smart contracts. We also use best coding practices to ensure we are not forgetting anything or we are not introducing bugs as we continue to develop the standards and improve the smart contracts. Security is part of our everyday processes. We also have a good culture of code review, where any changes go through multiple iterations from different reviewers internally in the team. We also conducted a lot of audits (7 in total to this date) as we were designing the LSP standards, and new changes were reviewed by well-known and reputable auditors from this space.
At LUKSO, there are a lot of teams working on a lot of different projects. For instance, we have a team for smart contracts, the backend and the browser extension, and more. We often try to review the code from other team members different than the ones we are in. This helps us by having different insights and also helps to improve our culture around security and clean code.
On a more individual security level, a huge part of the discussion in the creator economy revolves around counterfeiting. How has LUKSO mitigated more ‘traditional’ concerns like this one in your new ecosystem?
Counterfeiting is a complex issue that applies to a lot of domains and products. I think some of the token standards like LSP8 can help with that, to create uniquely identifiable digital assets. But there is still the challenge of creating a link between the physical products and their “digital identity” on the blockchain (and on the internet in general). This is something that in my opinion has to come on a more case-by-case basis. If we have a good list of existing problems from existing industries around counterfeit products, then it might help to design standards and solutions that are flexible enough to be used for these different categories (instead of different solutions per use case).
Right now I think the combination LSP4 + LSP12 helps to solve the problem really well for NFTs and digital assets. This is helpful to guarantee that the NFT you are buying comes from the actual creators, and it’s not a fake airdrop organized by scammers. For instance, when the digital asset is deployed on LUKSO, if it uses the LSP4 standard under the hood, the digital asset can contain the list of creators for the digital asset (under the LSP4Creators[]) data key. But anyone can state anything, like saying “this is a piece of digital art from the Karl Lagerfeld digital wardrobe collection!”, to fake it and make it sound real. LSP4 combined with LSP12 mitigates this problem quite well. You can look up the address in the LSP4Creators[], that should contain Karl Lagerfeld Universal Profile’s address, go to its Universal Profile, and check inside its Universal Profile LSP12IssuedAssets, which should contain the address of the Digital Asset. So through cross-references like this, you can have a form of proof (of course you still have to ensure that it is the real and actual Universal Profile of the brand you are looking for!).
As a self-determined ‘open playground for innovation’, what role do you see LUKSO playing in shaping security within the wider web3 ecosystem?
I think the idea of focusing more on standardization, in the sense of “standard ways to build interactions between users in a blockchain ecosystem” helps to reduce the level of risk when projects and contracts interact with each other. If multiple participants and projects use all different types of standards and build their infrastructure with different standards or in a custom manner, then that creates more risks and more potential areas for hackers and cybercriminals to look at to find potential exploits. If we focus more on building standards flexible enough to enable multiple custom use cases, but we are sure that these standards have been reviewed and audited regularly, then it creates more safety for builders and project owners as well as more certainty for users because you know that the applications you are interacting with are built on a safe infrastructure.
I often give the analogy of eCommerce and SSL certificates. When you shop online and you enter your credit/debit card details at checkout, you look at the SSL certificate on the navigation bar of your browser to ensure it’s encrypted. You don’t have to know how SSL or TLS 1.3 encryption works. You trust the technology behind it and how it is built because it is something that has been standardized (by the Internet Engineering Task Force — IETF) and reviewed to ensure it is secure, robust, and usable by Internet users.
What prompted you to engage with Code4rena?
I think it’s the idea to have an even more polished and audited version of the smart contracts. We have conducted 7 audits, but since we are now on Mainnet, it’s really to make them even more robust, and have a lot of eyes coming from different angles to look at the security aspect of the contracts. It’s really the idea of “security hardening”. I also think it fits well with the culture and vision of LUKSO: blockchain-based accounts and standards built by the people for the people. Code4rena fits really well with this vision.
Apart from running an audit with us, what does your security roadmap look like?
We have been implementing more security checks automatically in the lsp-smart-contracts repository so that checks are performed more frequently as we introduce new changes in the code base. We will likely continue to include more checks in our development process. The idea is also to test the lsp-smart-contracts more for some example of use cases, and see what are the potential issues and vulnerabilities that could arise depending on how the smart contracts are used.
I think the idea is that with all the 7 audits + Code4rena, we feel the smart contracts are secure in their current state at the protocol level (the core source code of the contracts themselves). We now have to look more at the application level and how these will be implemented.
To wrap up, let’s finish with an open-ended question. We’re not halfway through 2023, and we’ve already seen some very impactful exploits in the space.
- What are we collectively as a community doing wrong? What are we doing right?
- How can we become better as a community regarding security?
I think security in smart contracts and web3 have evolved quite well these recent years. What I think is still missing when it comes to impactful exploits are a few things.
First, promote the fact that security MUST be part of the development process when building web3 projects and smart contracts — not something that is done after all the code of the smart contract has been written. Developers have to adopt a security-first mindset, create features and test with the “unhappy path” mindset. Meaning finding ways to test and interact with the contract that are unexpected, or not intended when it was designed. Code4Rena helps to foster this culture. I think it would be a good initiative for smart contract developers to learn how they can really integrate security as part of their regular development work. This includes things like workshops around security to teach people and to build CI and Github actions that integrate security checks and linting code on Pull Requests, to ensure coding best practices are adopted, or potential issues are not added as we add code.
Second, I would say there is still the need to encourage code clarity and best practices when coding Solidity contracts. This is especially the case around things that apply to any programming language, regardless if you are building for web3, web2 or any type of softwares. This include good code formatting, based on the Solidity guidelines (or conventions agreed by a majority of Solidity / Web3 developers), variable and function names, encouraging some smart contract design patterns and standard ways to write Solidity code to solve a specific problem (Hadrien Croubois from the OpenZeppelin team did a very great presentation on this topic at Devcon 6 in Bogota), and documenting code so that it is clear about the intent of what the code should do and how it does it.
If the variables / functions are badly named, it is hard to read and follow and if there is no documentation, it is more likely prone to some potential bugs, because the logic is very convoluted. This actually had happened at LUKSO with the LSP6 Key Manager in the function to verify the permissions for an ERC725X.execute(…) function call). The function was written in a very complex way and hard to follow. We refactored it with the smart contract team, broke it down in smaller functions to make the code easier to read and follow. After the refactoring, we understood the logic better and Yamen from the smart contract team found a very good bug that could have potentially led to an authorised address to drain the funds of the Universal Profile while deploying a new contract through the UP. So clean code is essential. If you cannot understand your code as you read it and the logic is complexly written, it is likely that you might have missed something and your code might have some bugs!
Finally, I think we need to keep thinking of all the security aspects around the project, not only on the smart contracts. If you are building a wallet, or a website for a relay service, the security of the front-end and infrastructure of your product is as important as the security of your smart contract as exploits can occur at this level as well. A good example is the EtherDelta hack a few years ago, where the hackers hijacked the DNS server via DNS poisoning to redirect to a fake EtherDelta website. The exploit did not occur on the smart contract, but on the website itself. Because we work and build web3 projects, we shouldn’t assume that security only applies to the web3 part of the project. Security applies to the whole aspects of the project / product.
Learn more about LUKSO
Website: https://lukso.network/
Twitter: https://twitter.com/lukso_io
Discord: https://discord.com/invite/lukso
GitHub: https://github.com/lukso-network
LUKSO’s $100,000 USDC audit with Code4rena began on June 30th, 2023, and will be open until July 14th. More details here.
The Ones in the Arena spotlights emerging and established DeFi projects and their founders, with an eye to celebrating and learning from them. The series’ name is inspired in part by Teddy Roosevelt’s famous quote, which has a central place in Code4rena’s philosophy.
