Cryptography

Recap 6/9 Sui AMA: Cryptography with Kostas Chalkias

This recap covers an AMA about cryptography with Kostas Chalkias.

Note: You can find the paper “Be Aware of Your Leaders” published on Financial Cryptography and Data Security (FC), 2022 that Kostas mentions on our Sui Developer Portal.

Introduction

Jen: We are going to kick off with our first Sui AMA. Thank you so much for joining everybody. We’re diving into the world of cryptography and I’m going to give the mic over to Kostas to discuss it shortly.

Kostas: Hello everyone, I’m Kostas, Co-Founder of Mysten Labs and leading cryptography. I was at Facebook (Meta) for three years, leading cryptography for the Libra project. You’ll know it eventually collapsed for various reasons, mostly because of regulation and auditors. Eventually we retired the project.

I had the opportunity to work with one of the first developers of Satoshi Nakamoto, Mike Hearn, on the like transition from the Bitcoin space to something that is like a permissioned blockchain for a number of banks back then. They were afraid of the Bitcoin revolution. Mike left the Bitcoin community and asked me to help him on the cryptography side. I worked very hard on zero knowledge proofs, accumulators, multi-party computation (MPC) back then — confidential transactions, and you will see how this applies to Sui today.

I also lead the proof of reserves and the proof of solvency effort on the crypto community. And it’s interesting. By the time we published papers on Financial Cryptography and Data Security 2022, one of the biggest conferences where blockchain startups and research can publish their work, two days after was the Luna collapse. And I explained to them why nobody is doing it right, and I was super surprised that some of our work had an impact.

I think that we (Mysten Labs) have one of the strongest teams. The five co-founders, all of us are ex-Facebook leads on different sectors. For example, I was the lead in cryptography, but I was also doing stuff on WhatsApp as well. So you might run some of my code on your mobile phones already. But the thing is, we tried to also build a team from scratch. Most of us are seniors, and we hired a lot of like leaders in this space in consensus, cryptography, engineering, and may other topics. We even created our own language, Move programming language. Our CTO (Sam Blackshear) is actually the creator of the Move language.

So we do a lot of research. As we move forward, you will see some interesting stuff, including some questions that I see here on zero knowledge proofs. I hope I can explain exactly what we’re working on.

. . .

Question #1: Sui’s advantage over other blockchains?

Jen: What are Sui’s advantages over other blockchains? And what are the reasons that will make users switch over to Sui?

Kostas: That’s a very good question. And actually, it’s one of the reasons that Mysten Labs exists. We’re providing a completely new paradigm on how the smart contracts are actually implemented. I will explain what’s the difference between Sui and Ethereum, for example. We have a combination of award-winning consensus algorithms. First, we have one of the fastest consensus algorithms and mempool; it’s Narwhal & Tusk. And second, there are some applications that can completely avoid full consensus and bypass it. For example, you can check out what we call Single Writer Friendly (SWF) applications. We have this different model of like ownership and certain objects, and the way you can combine it. Some of the assets can move from one place to the other, from one consensus to another method. And this is what makes a huge difference on our blockchain Sui.

Regarding Ethereum, as you know, is using the account-based model. At the same time, we have Bitcoin which is like the UTXO model. I would classify Sui as somewhere in the middle. We did this interesting trick where everything in Sui is like an object that can be transferred from even one contract to the other. On Ethereum, there are two points of congestion.

Imagine that on the user account level, if the user is sending transactions from the same account or there are some other users who are affecting this user’s account, for example, to pick up on the balance. This account is a point of congestion because all the transactions have to be ordered in a block. Otherwise, we don’t know which came first, if the account was drained before it had the opportunity to actually spend some money.
Second point of congestion on Ethereum is at the contract level. Imagine now some of the most popular contracts like ERC-721, ERC-20, etc. There is usually inside the contract a huge hashmap, huge vector, or something placed where we can actually hold the mapping between who owns what and what is the current balance or the current NFT. If there are multiple transactions in the same contract, this means that the transaction should be ordered between them in order to actually have a sequence of events. And again, not having a particular state where we’re losing information, because of unsuccessful ordering, this means that Ethereum has to create blocks. And because it orders everything, this is a slow process.

What we did is we removed this bottleneck. The removal is actually by decoupling the assets from the accounts and contract. So we have the address in Sui and this address owns objects. Imagine as NFTs, or even assets with a fungible balance, similar to UTXO. So these assets are accompanied by a version, by a nonce if you’re familiar with Ethereum. We remove the nonce from the Ethereum account and we put the nonce (this version) into the assets that you own. Now all of the assets live independently; you can touch one asset and you can touch another asset. Because these assets are not actually conflicting between them, you don’t need total ordering. And this is where our speed actually comes from.

We tried this as a little experiment on a simple Mac laptop and we achieved 120,000 transactions per second. This is huge. We’re not requiring a machine that requires huge memory and huge storage. This is where we actually sign. We believe we’re going to be the fastest one. Second, we’re using Move to protect the assets. On Ethereum, everything is uint256, right? It’s a value. How do you transfer one value from the other without having problems to understand what this means? The software developers or contract developers need to know exactly what they’re doing. And this is prone to potential attacks that we’ve seen in the past.

Shortest answer on why Sui is better: speed, programming language, object oriented, and ultimately, easier and safer because of this object-oriented mentality. Users can make less mistakes on their code.

Question #2: When is testnet? Is it incentivized?

Jen: Now, the next question we have is: when will testnet start? Is it incentivized and can active testnet participants become validators on mainnet?

Kostas: I will reply quickly on the incentivized thing. Yes, it will be incentivized. We’re still working on the details and we’re building the ecosystem and the community at the moment. We will incentivize contributors, as well as from external developers. Imagine tooling apps for testing, documentation, bug fixes, etc.

But the full details on how this will happen? It will probably be a topic that someone else in the next AMA will actually answer.

I can explain a bit on how are going to technically give incentives to people to work on. For example, we need to transfer all of the Ethereum popular smart contracts into Sui, because this will make sense for the transition and create a template. And this will incentivize people to participate, usually, because it’s very easy to write code on Sui. I personally wrote a Twitter example with 50 lines of code. If you go to my Twitter account, you will see my post; I call it Suitter. And you will realize how easy it is to contribute. We actually recommend you do that. Start at our GitHub repository and start posting things that might be like a clone of the Ethereum blockchain.

We actually need Sui to have all of the functionality of all of the other blockchains. We know it can happen. We know it’s even easier to do, especially if you’re coming from an object oriented language like Move. Move is inspired from Rust, but it doesn’t need to be a Rust developer who joins Move. Or even a Java developer or someone else because we’re dealing with objects. This can help you a lot to move quickly from your conventional software to smart contracts. Do it now because testnet will definitely be incentivized.

Question #3: What is the goal of Sui?

Jen: On top of all that, what is actually the ultimate goal of Sui? How is it unique? Who is it ultimately looking to cater to? And are there any partnerships that we can expect coming out soon?

Kostas: Imagine all of the founders are coming from FAANGs, like Facebook, and some of us have prior experience with blockchains. We’re exposed to many applications and startups that are requiring blockchain functionality. The goal for us is to actually have a stable, safer, and the fastest blockchain out there.

I explained things in the first question. And from what I can see, we’re getting towards that. We achieved a lot of milestones already. The ultimate milestone is, obviously, to be the leading blockchain to write smart contracts. Our system is delegated proof of stake. Because we have one of the fastest algorithm for consensus, and as I explained, you can even bypass consensus for some applications, this will make us the leader in industries. Imagine gaming, there is a trend, like having all of the gamers to be actually incentivized to participate in blockchains. Being able to sell their assets is easier than being in an isolated environment. It’s also DeFi because we have the fastest consensus; we believe that DeFi is also going to be like a killer application on Sui. You can even do, as I said, a Twitter on the blockchain. So any chat messaging is super fast with us. Low and even subsequent finality, because you can bypass consensus, and in the worst case, it might be a couple of seconds finality because the consensus is fast. So we believe we’re going to lead the space of DeFi, gaming, and anything with commerce. In general, it’s like a modern Ethereum. And because of this, we hope we’ll be one of the leaders.

Question #4: What happens if owner is malicious? Wouldn’t consensus actually be needed?

Jen: In terms of owned objects, it can only be modified by the owner. So you say consensus isn’t really needed for them. But what happens if the owner is malicious and tries to double spend? Wouldn’t consensus actually be needed for instances like that?

Kostas: So when I say we bypass consensus, a lot of people who are not familiar with the algorithm will obviously think of this particular use case, right? What’s happening if they use it as malicious. If the user is malicious in practice, they’re creating problems for themselves. Imagine you own something. If you try to actually play a game and send to 50% of the validators your transaction, one transaction with an object and another transaction with the same object, obviously, this object will not be able to be finalized.

You always need a quorum of signatures, which in our case, is 2f+1. So 67%, let’s assume that we had 30 validators, you need 22. You need this number of signatures to receive. Our validators obviously track what they’re signing and it’s impossible to double spend. The the worst case that can happen is there is an equivocation state where your object is actually getting frozen. And you cannot update it because it received 50 and 50. You cannot go more than 50 in this particular case, and you’re creating the problem to yourself. However, we have a mechanism. When it’s epoch chain, there will be some gossip communication between the validators and the frozen assets will be unlocked, and will be able to be used in the next epoch. We haven’t identified yet, and this is actually tested in the community, any particular case where malicious users who own assets have incentives to lock their particular object. The only thing that can happen is actually creating a problem to themselves by doing this equivocation scenario.

Question #5: How do you bypass consensus?

Jen: We actually have another question that that ties into that. Can you explain how you bypass consensus?

Kostas: Okay, cool. Let me now actually send you a link on Single Writer Friendly apps. So if you go there, we can actually go one by one and see why these applications have this benefit of bypassing the consensus. Whoever clicks on it, you can see a list of 22 applications that I have here, all of them have something in common. This can work on the single writer model, which means that actually a user owns something, is responsible for submitting these or transferring this asset to someone else, or mutating this object. As I explained before, the worst you can happen in this particular case, if you’re not careful or you’re malicious, is you’re actually freezing your asset. But in the happy path, you’re not going to do it.

And assuming most of the people will be honest, imagine the regular p2p transactions:

You go to Starbucks, and Starbucks actually wants some eventual finality for you to actually sell you the coffee.
And what you do is you’re sending your object to the Starbucks account, the address to the Starbucks address, and then you will receive 2f+1 signatures from the validators independently. They’re not going to the consensus.
Actually, the user is connecting to all of this 2f+1. There will be a gateway, there will be some driver who who will do this work on the wallet side, and then you will receive 2f+1 signatures. The validators internally keep the version so they know what they signed about this particular object.
And now, you can provide these to Starbucks. This is eventual finality, and your Starbucks is 100% sure that this transaction will reach a block in the future.

It’s impossible to get 2f+1 signatures and not go to the blockchain, which is like a secure light client mode. Because you got 2f+1 signatures on parallel interdependently, we guarantee this protocol only accumulate signatures. This is called fast pay, by the way, and you can search about the original work about how you don’t need full consensus, and our white paper about how we managed to connect all of these dots on Sui. So it is possible with this model to only accumulate signatures. And this is an undeniable proof that this will eventually go to a block. And because of this model 2f+1 on parallel communication, no n² in between nodes communication, which means low latency subsecond, it’s actually speed of light here.

And all of these applications here, it’s like regular p2p transactions, confidential transactions, because there’s no difference between transferring real balances against confidential balances. For example, MimbleWimble and Monero are doing this public bulletin board. So if a user wants to publish something on chain, they own it, and they want to do mutations over this object or they want to transfer something to someone else, you don’t need full consensus, right? Because you don’t really care if other transactions on chain are happening in a different order. This is your object, you’re transferring it to someone else. If you try to equivocate, the only thing that you might have to do is freezing the object. So you don’t actually need the default consensus. And then, we have someone now has an idea on a startup about creating the Signal protocol, WhatsApp protocol, Twitter protocol, a new Yelp, and new TripAdvisor with shopping lists, even a personal GitHub, or personal password manager. Knowing their active games, imagine if you evolve your Sim City, your FarmVille state, right? You can actually bypass consensus here. You don’t need full consensus, to have this evidence that the transaction who only received signatures will go to a block 100%.

Decentralised lotteries — imagine what is every ticket that we buy? It’s an NFT. By NFT-izing, everything in our particular case, everything is an object, you’re just creating an NFT intervention at the very end, only to identify a winner. You probably need full consensus, but the tickets can be purchased without full consensus.

Imagine even posting price quotes. You don’t necessarily need to bypass consensus on every step for every application. It is highly possible even on DEXs to have a few of the steps be a single writer that they don’t need full consensus. In this particular case, we have oracles who are posting price quotes, the posting of quotes can actually be a single writer; it doesn’t need consensus, I’m just posting it. And then the one who does the aggregation or the trade, then they need full consensus. So we manage to actually even combine this in the same application model.

You can imagine having job listing applications like you can create a workable or LinkedIn. In this particular case, you can literally avoid full consensus. Nobody’s asking you if you posted something before someone else on LinkedIn, and the ordering is slightly different. Eventually, they will go to a block anyway, so they will be ordered. But at the very beginning when you need undeniable proof, you don’t care about ordering.

I think I covered most of them. I’m super happy if you can propose other applications in this chat thread so I can add them. And this can even be considered some type of interaction from your site, as we say from the incentivized testnet, you can even help us to identify applications who are friendly with our Fast Lane; I mean, applications that can even bypass consensus. But even if they don’t, we’re still the fastest protocol out there.

Question #6: Plans to support ZK proof verification?

Jen: Are there any plans to support ZK proof verification in Smart Contracts? For example: Zokrates, Nova, Spartan, etc.

Kostas: The answer is: yes. And why and how we’re going to do this right? What is a blockchain in practice? The blockchain is a smart contract language Turing complete, where everyone can build whatever they want on top of it. Personally, some of you might know me because I was a product leader of the Winterfell STARK zero knowledge proof system. It was one of the publications from AsiaCCS. (By the way, the “Base64 Malleability in Practice” won the best poster award.)

So I’m super familiar with zero knowledge proofs. I also use bulletproofs in the proof of solvency as standardization process that I’m leading. So we have all of the capacity to do it. And what we’re planning to do is the Move language. Now we have Ethereum, and if you go to the yellow paper of Ethereum, you will see all of the transactions, all of the commands that you can actually have on your contract. We will augment Sui to also have extra primitives so that people can more easily build zero knowledge proofs on top of our system. And what are these primitives? One of them is, let’s support Pedersen commitments. If we support Pedersen commitments, then one can build all of the systems that can provide extra privacy to the smart contract.

Also, because I’m familiar with bulletproof and we are backed by a16z, people are part of a portfolio of helpers or researchers who help the portfolio companies, we will work very closely together to have an API and bulletproofs. So we can have range proofs eventually on Sui; it might not be directly on mainnet, but we are going to have support for adding it as fast as possible. And then because of these applications, and because of the fact that we might even allow bilinear pairings, someone can even build other schemes like inclusion proofs in Move like accumulators and polynomial commitments. You can even build vertical trees with polynomial commitment. Eventually, we want to incentivize people to build ZKP verifiers in Move like Groth16, PlonK, etc. I’m familiar with Starks and Winterfell. And this is part of the long term plan. But originally, bulletproofs and Pedersen commitments are pretty much a priority, plus some fraud proofs. We have some very cool applications on utilizing fraud proofs when we believe that ZKP is expensive.

And this is like an announcement here: We even have a protocol on how to do semi-private NFT. What I’m saying is, we are going to provide and allow primitives on top of the Move API. And these primitives will allow us to do all of these cool gadgets and things on top of Sui. So most of the zero knowledge proof verifiers will be, even if not implemented by ourselves, we will have some of the primitives that can be used from you like bilinear pairings or Pedersen commitments. And I personally want feedback on this. What would you like to see that can be reusable as a primitive in Sui? If you send us a list of things that you believe are useful for you to innovate and have your own startup and actually build some very cool, I don’t know, bridges or other stuff? Let me know. And I can make sure that whatever is possible from our side will be there.

Question #7: Is Sui blockchain quantum resistant?

Jen: Is Sui blockchain quantum resistant? If yes, how will it be implemented?

Kostas: This was one of my expertise, skills that I used to actually perform at Facebook as well. There are many ways I call it post-quantum readiness. And in this particular case, there are many ways to enforce post-quantum when you need it. At the very beginning, we’re going to support EdDSA as a signature algorithm. Very soon ECDSA as well, because there is a request from people who are familiar with Ethereum who can’t wait to use the same key type on Sui. Yes, after many discussions with stakeholders and partners, I decided we’re going to add this. Because there is these crypto agility, so you can define and flag of what private key type you’re using or public key type, then in the future, we might even consider to have a post-quantum scheme there.

I’m the main author of the blockchain post-quantum signature, it’s called BPQS, it’s a variant of XMSS. So there is an efficient implementation using only hash functions. I’m not sure if we’re going to use exactly this in the future. So at the very beginning, we start with non post-quantum. But we will build out our chain in a way where, with the flip of a button, people can actually move to post quantum keys.

There is a catch here. What’s happening with those who have assets on a quantum like non resistant algorithm like ECDSA; there will be a period where we will allow assets to be transferred from their non post quantum to the post quantum alternative. Or there is a nice trick here. If you’re using deterministic algorithms, like EdDSA, there is a way with Stark proofs; imagine, the zero knowledge proofs with Starks can provide post quantum security. So if you can prove knowledge of the pyramids of your private key on an EdDSA key generation, because it uses a hash function internally, then in theory, even users who are using conventional crypto, they can actually move very quickly to post quantum settings. I’m preparing a paper around this, and listing all of the methods that conventional blockchains can actually use to jump in a post quantum world.

Question #8: Sui integration on hardware wallets?

Jen: Do you plan to integrate Sui on popular hardware wallets?

Kostas: Yes. So we have Todd, Head of Engineering, who is already on this thing. There will be a spectrum of key types that we support from ECDSA, which are compatible with Ethereum, to EdDSA, which like the most modern variant of elliptic curve cryptography, the probability of actually building something on hardware wallet is like favoring cash because anyone can pick whatever key type they want and then they implement it on the hardware wallet. We need partners in many cases around this. But we are going to also work by ourselves on having a plugin on some of the most popular hardware wallets. This is not a goal for the mainnet, but it’s a stretch goal. And probably we’re going to have it if we find the suitable partner here.

Question #9: What are expected specs for nodes?

Jen: What are the expected specs for the nodes? And what is the maximum size of the ledger? How do we avoid dust attacks to overload node disk space?

Kostas: As previously discussed, we can parallelize stuff. We can scale horizontally in many particular cases, which means we just spin up new nodes to do signature verification. How does denial of service attack happen? There are many ways to do this, but one of them is you’re actually signing transactions that will fail eventually. And they will probably fail at the signature level, which means that you cannot even charge gas for this denial of service. The other thing is where people are actually submitting so many transactions, as this happened in Solana in the past, there is a dominant smart contract, which actually receives all of the traffic and it doesn’t really allow other or even the same contract transactions to be executed. Because we can finalise stuff and we can actually split the consensus, the logical execution ordering between different smart contracts, imagine all of them can run in different consensus, there will not be a dominant contract that will actually ruin the success rate of the network itself. So we’re more secure in that sense, because sharding capability is embedded into our system. So this is where we sign actually because of parallelization, even at the consensus level, and because of the fact that many applications can even bypass the consensus level, the whole network to be done is by far less probable compared to other blockchains with an older architecture. But we know exactly why we’re better than the rest. And because we’re like the second player in this game, we’re also learning from the others. And we believe we have a better system against denial of service.

(I mean, I like many of them, right? I was also a crypto safety person. I named my son Kryptos. My son’s name is literally something about the work I’m doing, and cryptography and cryptocurrency in general. How I convinced my wife is a completely different story. It’s not a joke. If you ask me about my name, you will see on my LinkedIn, it’s Kostas Kryptos. Kryptos is my son’s name with a K, because we’re Greek background. It’s a word in Greek by the way; Kryptos means hidden secret.)

Question #10: Do you plan to shard the network?

Jen: Do you plan to shard the network

Kostas: As explained before, it’s embedded in the network. It’s not like AVAX where there is some domain separation. This is also a cool technology; I personally like them. But I think we have a better system on how to organically scale and have these internal service mechanism, which is more natural. You also get all of the consensus guarantees in the whole L1 network compared to splitting to subcommittees and all of this stuff. I think our model here is slightly better.

Question #11: How is gas set?

Jen: Can we set gas like ETH or MATIC, or gas is set like Solana?

Kostas: Okay, so there is an interesting application we’re working here. You can even have meta transactions in our case. You define in our particular application how much you want to spend for a transaction, but there will be a possibility that you can even delegate your transaction. Imagine you’re sending a transaction, you can delegate to someone else because you don’t have enough gas. And if the program will see these two signatures, it will get the gas from the person who helped you and will actually execute the transaction that you want to do. This is very important, right?

Imagine people are going to receive NFTs. They might not even have a single SUI coin in their account, but they’re going to transfer their NFT and maybe because of this meta transaction support, we can allow other wallets to help them. Maybe these wallets will use it as the advertisement campaign: I will help you, but create an account on my website or watch this advertisement or something else. Or you can even have some custodial services that will do it for you, and you pay them in a different off-chain manner. So it will be. There will be a case to help onboarding people who receive stuff. Eventually, they’re going to have support for spending, transferring, mutating their own assets, if they find someone else to actually pay the gas for them. And because we’re expected to have one of the lowest gases in the space, because we’re faster, we can scale faster and organically, so we can drop the prices and be more secure against denial of service attacks compared to the rest.

We believe that this will give incentives for onboarding into the space of blockchains, especially the gaming community. You might own NFTs, but you don’t have coins. But if the game studio is helping you to spend stuff, then why not use SUI because it’s almost free?

Question #12: How do private NFTs work?

Jen: How do private NFTs work?

Kostas: I can’t share my screen, right? I can actually make a short presentation of the private NFTs. I’m planning to publish and this is one of the reasons I’m not having everything exposed at the moment. But I can give you a very quick example. Imagine you have a Bored Ape NFT. Usually you can see everything in the Bored Ape, but what if some of the pixels are blurred or there is an overlay like a watermark on top of them. And you want to prove, because what you’re buying right on the blockchain, you are buying hashes. You buy the digest of the picture. And this is like something that says you buy a commitment to the picture, you buy a commitment to the NFT.

We’re using some cryptography at the moment with fraud proofs, where you commit to the encrypted NFT, partially encrypted, you can see most of the image, but some of some of the pixels are blurred. So nobody has the exact same copy of what the Creator is selling. And then if the Creator doesn’t give you the the original NFT by decrypting key to your public key, then because the commitment will not match, you can actually create a fraud proof that says: “Okay, I bought a different hash and you sent me a completely different image, which is not what you were supposing to sell.” It’s the same thing as Amazon books. Now Amazon Preview, what do you do when you go there? You can only see a few sections, some of them are actually retracted; you cannot see them. You trust Amazon though, right? You trust Amazon that when you buy something, they will give you all of the pages of the book that you bought? How can we transfer this web2 technology to web3?

Now, we did pretty much the same thing. But we added cryptography. So if the current seller, let’s assume the Amazon on Sui, is not giving you what you would expect to get, as other people go out and added some like reputation, let’s say stars. You can go against Amazon by providing fraud proofs: “No, no, I didn’t buy this thing; I want to get refunded.” And this is how it works.

Question #13: Implementing zk-SNARKs in Sui?

Jen: And are you looking forward to implementing zk-SNARKs in Sui?

Kostas: What is the support for zero knowledge proofs? zk-SNARKs is a zero knowledge proof scheme, right? As previously discussed, yes to bulletproofs for now, like for confidential transactions and Pedersen commitments. And because we’re planning to allow primitives on chain, like bilinear pairing cooperations, even if we don’t implement the proof, the verifier on chain, because you need the verifier, we will give an opportunity for users to do with less gas compared to other systems where you have to implement everything. And it’s not part of the main network, that’s third-party operated.

Question #14: Are you going to spin up many nodes to sign transactions to scale horizontally?

Jen: When you say we are going to spin up many nodes to sign transactions to scale horizontally…

Kostas: Validators? Yeah, the validators can actually be one machine as it’s now in Solana. But in our case, there is no reason to be one machine; you can actually have multiple copies.

Question #15: What is the difference between Sui and other projects on Move?

Jen: What is the difference between Sui and other projects that are building on Move?

Kostas: Regarding the programming language, this is the only part that we’re using between other platforms and Sui. However, our Move, our variant, is splitting everything into objects. We offer this capability of getting to the fast lane and bypassing the full consensus here, because we’re object centric. The other projects are account centric. And you will see there are some very basic differences.

If you see my Twitter example (aka Suitter), and see my post about how I did this in 50 lines of code. Because everything now is NFT in our case, you are using Move slightly differently compared to the rest. Sometimes it offers some flexibility on making different sections even cheaper. The only thing that we’re using between the other projects at the moment is the language itself. We’re using the same language, but the way the construction of the object is internally slightly different.