Learn about Arx Halo Chips - ETHGlobal Bangkok 2024

Hi, I'm Cameron. Today we're going to talk about Arx Halo chips. Arx Halo chips look something like this, like a normal NFC tag, but they're actually way more powerful. They are a full Ethereum signer. So, you can use them to sign Ethereum messages.

You can use them to send transactions. You can do anything that you do with a hardware wallet using one of these small chips. If you'd like to grab these chips during ETH Global, come find us. We'll have somebody at ETH Global Bangkok. Otherwise, they're built in to all of the ETH Global wristbands.

So, you can always tap a chip to generate signatures. This workshop is going to be in two parts. Uh in the first part, we're going to talk about ERS. ERS is a protocol for resolving Halo chips against assets, against the manufacturer, and against the project who embedded them into something. It also allows end users to claim ownership of chips via the PBT or physical web token.

Um that's a lot of details. We'll get into that. The second half of this workshop, we'll look at the Halo demos, which are great ways to interface with Halo chips entirely via web browser, and they'll show you how to do things like generate different kinds of signatures. So, getting started with ERS, you can hop to ERS.to.

And then take a look at the docs here. We're going to jump into the ERS scripts. So, grab yourself a copy of ERS scripts. And what you'll want to do is read carefully the setup section. Uh let's go ahead and get the dependencies installed here.

And you'll also want to make sure that you set up an environment, an end file with all the environment variables that you need. So, that'll include things like a Superbase account, which allows you to access the Arx manufacturer enrollments. A Firebase account, which allows you to create token URI data. So, think of an NFT where you have all the metadata associated. That metadata is stored via scripts on Firebase, which is uh an IPFS host.

And then an Alchemy account to handle all of your RPC needs. You'll also want to have private keys which have some funds in them on base. The private keys are used for different roles in ERS. Take a look at the ERS docs to understand these roles a little bit better, uh but at a high level, you're going to have um manufacturers, developers, owners, service providers. In nearly all cases, as a developer, you'll you'll be the developer role, and then you'll also be a service provider.

Uh super quickly, developers are within the ERS namespace. They claim their own part of the namespace, and they then go ahead and enroll projects. Services can be developers as well, and they're what chips redirect to. So, say you have a chip that redirects to a dapp, that would be a service. And services are immutable.

Projects are effectively immutable. So, you want to think very carefully about when you add chips to them. So, we're close to installing ERS scripts now. Okay, so we're going to go ahead and get started using the scripts here. One other quick reminder, which I skipped previously, is we want to go ahead and run yarn build, and that'll get us a local set of the ERS contract artifacts.

So, let's go ahead and run that. Should just take a moment here. Great. So, in a typical flow, you can create a service or developer registrar in either order. Uh we're actually going to start here with creating the developer registrar.

Um Every one of these scripts is pretty simple to invoke. Uh you'll want to add a network parameter, and the production deployment of base is on base. So, we'll we'll go ahead and add that parameter, and then you'll be prompted a series of questions. So, let's go ahead and get started here. We will So, we're prompted to enter the name that we'd like to claim the ERS namespace.

Most common names are pre-claimed for now to prevent people from sitting on top of potentially valuable names for different brands. Uh so, you might have a hard time finding a name. If you have a unique name that hasn't been used before, you can come find one of us, and we can help release the name specifically for your project. But for now, we'll come up with a simple name that should not be claimed. So, we're claiming the name ETH Global test against the signer, which is in our end file as the developer.

So, we'll now be linking ourselves to ETH Global-test. This is going on chain and doing a couple of transactions here, so it might take a moment. We're now deploying our developer registrar, from which we will add our projects to. Perfect. We now have our registrar, and what we've done is we've actually created artifacts that we can take a look here in the task outputs folder, and we can review, okay, great.

This is my developer address, and I can see the developer registrar that I just deployed here. Perfect. So, what we'll do next is we'll go ahead and create a service. Again, a service is where we're ultimately going to direct chips to a specific set of content. All right, let's call this ETH Global app.

This is either a URL, which is what I'd recommend. So, for instance, http:// Let's do https:// app. ethglobal. com, or it could be a decentralized app such as IPFS followed by the the CID of where the app resolves. But we'll stick with something centralized for now to keep it simple.

The next question is whether or not you want to append chip IDs to the end of the This is typically not an option that most people need. However, if you're adding rich metadata against chips, this is really helpful, because the way in which the metadata is built in the create project task, it will anticipate that this option has been selected. So, let's just say you were deploying uh 1,000 chips, and each one of those chips had a unique image associated with it, like 1,000 unique NFTs. This is where you can bundle everything up into IPFS, into a single CID, a single resource, and within that IPFS, let's just say that IPFS folder, you have each one of the named resources for each one of the chips in that points to all the unique images and the unique metadata. And so again, here append make sure that when you're resolving through ERS, you are appending the chip ID, and if you use the scripts, that chip ID resolves to unique content.

If all the chips are pointing to the same URI, the same app, you don't really need to worry about this. So, in this case, we're going to keep this simple, uh and we're going to go with no, we don't want to append chip ID information. Everything will go to the same content. Okay, so we've created our developer registrar, and we've claimed our part of the ERS namespace. We've created a service which has the content that we're going to link chips to.

And now we create a project which really binds everything together, and that's where we add the chips and ultimately link them into the service. So, what we've gone ahead and done is we've actually created a task params directory, and we've copied the files from the example directory into task params. And that'll become relevant in just a moment here. Let's go ahead and run this command on base as we've been doing. We'll be prompted again with another set of questions here.

We're going to create a new project. And you have a few different options. As mentioned before, if you're creating something with a bunch of unique metadata per chip, you can do that via a specially formatted CSV file, and you can take a look at that example CSV file that I mentioned earlier to see how that's formatted. Or you can skip it and add this information later, or maybe you simply don't need token URI data. The difference between token URI data and services is important to point out.

So, services again are more like apps and URIs that you want to direct the chips to. Token metadata is similar to how you would associate metadata with an NFT. So, an NFT might have images or videos, text, etc. associated with them. Um and it just may be that the app is what renders that metadata in a specific fashion.

But if you're just using it to redirect a chip, you can probably skip it. For the demo, we're going to go ahead and generate some custom token metadata. Uh in the task params, I've taken the token URI example, and we'll go ahead with that option. And we see here that the scripts, because I've saved the artifacts as I progressed through this automatically in the background, have picked up my developer registrar, ETH Global test. Time to name name my project.

Let's just call this the ETH Global Bangkok test. Great. Similar to NFT projects where you have a symbol, here you also can come up with a symbol. Um don't worry, it's non-unique in the name space, so if it's used it won't prevent you from using it. Next up is a question around how long do you want to lock in the redirect URL for?

This question is relating to one of the interesting properties in ERS, which is ultimately end users can control what chips point to. However, we give the initial development the option to lock things in for quite a long period of time, upwards of 10 years. And the reason for removing a lock-in is ultimately, let's say a developer links the chip to a service that goes away, they no longer host it. In order to maintain utility for that chip, we give the end user the ability to then redirect that. We're not going to put any lock-in on this chip and confirm that.

And then lastly, we've picked up the services we deployed, blah blah, and we'll like that. So, right now we're going ahead and deploying the project on base. We've deployed the project registrar and we're going to now add that project registrar to the developer registrar. And that helps us to resolve all the way through the name space so that we understand that. So, you can see that depending on the size of your shell, you may or may not have issues rendering a QR code, which is a QR QR code is pretty important because it is actually what is going to allow you to link your smartphone to the scripts themselves.

So, let's go ahead and copy the QR code or the base 64 of the QR code. And we can go to an online rendering tool here. Great. We'll go ahead on our smartphone and scan the QR code. And what's happening is we're actually opening up a web socket here between the instance of the scripts and our phone.

And we can see here that our smartphone has connected and we have a piece of content that was found in the CSV, which is going to be linked to a chip. This is the first edition, there's a name, description. And what I've done in the CSV is I've actually edited in the full path to the media, which in this case is cache.jpeg. You need to do that, the script will fall over if you don't, so.

Let's go ahead here and we can hit confirm and scan the chip that we want to link to this image and content, so. Scan the chip. And what we're doing now is we're uploading the information to IPFS via filebase. We're outputting the token data and we've gone ahead and added that to IPFS and pretty soon we're going to go ahead and add that to the project's token URI data. We're calling add chips on the contract now.

Great. Now we've added the chip to the project registrar, we have our first chip enrolled. We're basically good to go. Um this chip should be able to redirect through ERS to the app and if the app were so equipped, it would be able to render out this token metadata and show off this this beautiful image. Um there's one last thing that we can test, which is claiming ownership of the chip through through the protocol.

Depending on how you're using the protocol, you may or may not care about using this. Um as I noted earlier, every chip is repre- represented by a PBT. You can learn more about what a PBT is at pbt.io. Uh it's a new and novel standard which includes an EIP which is currently under review for basically creating physical back tokens or something like an NFT linked to a physical thing.

Um the difference between this and a normal NFT, if you were to associate with a chip is you could remove the normal NFT from the chip, but a PBT doesn't work that way. It uses signatures from the chip to change ownership on chain. So, coming back to ERS, every chip in ERS is represented by a PBT. And we can go ahead and transfer that token at any time. So, let's just go ahead and demo with that with this chip that we just enrolled.

So, similar to the previous task, we're going to get a a fragmented QR code here and depending on the size of your shell and the system that you're running on, you should be able to scan this directly without needing to copy and paste it as I am. But that's fine. We'll go ahead and paste this in here. Great. So, we'll go ahead and open up the web socket by scanning this URL on our phone.

We need to connect. And perfect, we can see that we're connected and we've been prompted to scan the chip. So, we will scan the chip that we just enrolled the project. Perfect. We're looking up the chip ID right now in ERS and we found the current owner and we are now making a claim for a new owner.

The new owner's private key is something that you need to add to the environment file, so we've gone ahead and done that. And in a moment here, the new owner will claim ownership of it. By default, the way ERS works is the first owner is the project creator and then subsequently, anybody with possession of the chip can claim the PBT. Again, depending on your use case, this may or may not matter, but it's certainly nice to have a representation of the chip on chain in a fairly simple fashion. So, we've now come to part two of the workshop, which is lib halo.

Lib halo is an SDK for interacting with halo chips entirely via web browser. It's really great because it works on multiple platforms, you can use it on iOS and Android and there are also ways to use it via desktop computer. Lib halo makes it really easy to capture signatures from halo chips and then to go ahead and and leverage those in smart contracts in other ways. So, it's a low-level utility, but if you want to do an EIP 191 signature, an EIP 712, it makes that fairly simple. So, definitely take a look at the repo.

The repo has the most in-depth documentation on how to use lib halo, but for most of the interesting hacks, you'll definitely want to take a look at it. The lib halo demos in general are best used on a smartphone because smartphones are where you have your NFC scanners. You can use a hardwired NFC scanner, but unless you have that with you now, you'll you'll likely be using just your smartphone. But we will demo one thing via desktop, which is the halo gateway requester. So, the halo gateway requester is the same thing that we used in the CLI examples before with ERS.

Um and basically what we're doing is we're establishing a web socket between this browser instance and your phone and you're using your phone as sort of an NFC scanner to capture information. So, let's move myself to a different part of the screen so you can see what's going on here. So, in this demo, we're going to use the default lib halo gateway, which is a free service provided unless you want to host this on your own. This is the easiest way to do it. We'll go ahead and make an EIP 191 signature as opposed to a raw ECDSA.

You can also, of course, do EIP 712, although this demo doesn't show that. And we'll just sign this random message here. Again, we come back to the QR code generated. My phone in camera mode. Let's go ahead and scan that.

Cool. So, we can see both on desktop and on my phone here, we have now created a web open up a web socket between the two and I'm going to click confirm and scan halo and we'll go ahead and scan the halo. We got that information returned. So, we can see here we have just signed this random number. You can see the digest, which is the hash of that, the message and of course the signature.

And the nice thing is we produce the signature both in sort of a raw ECDSA form if you care about that or the much easier to use Ethereum formatted version. So, that's lib halo on the desktop, but most of the other demos you want to use directly on mobile. So, what I'm going to do here is show you in the small circle some of these demos. So, let's go ahead and choose the demo at the top. We'll follow along on the desktop web browser, but most of the action will be occurring here on my phone in the center.

So, similarly, we have a message digest to be signed and we can choose the key slot from which to sign that. So, we're going to use key slot number one. Most applications, that's all you care about. Depending on the halo version, you'll have different sorts of key slots. On the ETH global bracelets, you should have a number of them.

Again, we recommend in most cases for building a demo, you can just use key slot number one. Other key slots may require passcodes and have other more advanced features. So, depending on what you're building, you might want to take a look at the lib halo docs which enumerates which key slots and the capabilities of the chips, but otherwise, we'll we'll use key slot number one. So, here we've got that set up. We've got our random message set up.

At the bottom here, I'm going to go ahead and sign using auto detect method. Depending on whether or not you're on an Android, you can actually call this via a couple of different ways and you can see here, similarly to my desktop example, we've gone ahead and generated an Ethereum formatted signature where this chip is the signer. There's a number of other demos for different features. I recommend taking a look at lib halo to see if you want to use any of these features. Um you have the capability to do things like graffiti where you can add a message that can be overwritten by any person who has the chip.

You can also do things like get data struct, which allows you to retrieve multiple pieces of information from the chip, say multiple keys all in one shot, so within one tap. The workshop today, thanks for spending time with us. If you have any questions, please feel free to reach out. And of course, we're super excited to see what you build with lib halo and ear us. Thanks a lot.