Transkrypcja: Workshop: Crypto Exchange for Developers part #2

Opis wygenerowany przez Skrybot

Dla tego filmu nie wygenerowano opisu.

Transkrypcja wygenerowana przez Skrybot

So maybe we can start and as usual, I'm gonna say a couple of words about Datum, we are what we are doing and what should we do and how we should start and what's gonna be in today's workshop. So Datum is a next generation blockchain infrastructure. You have REST API, we are REST API cloud service where you as a developers have access to more than 20 blockchains and you can work with thousands of crypto assets of ERC20, strong assets, Binance Smart Chain coins and stuff like that. We provide you with a free plans for development if you wish so that everybody can just sign up into our dashboard, obtain API key and start just playing around with the API.

And when we sign into the dashboard, we can create free API key here. Everyone can create three free API keys and when you do so, you can just obtain API key which is necessary for communicating with the Datum API. With this API key, you can invoke any REST calls to Datum. So now let's jump into the workshop as such. Last time we covered basically everything from this guide. This guide is available on DocState. myO. You can find it in the developer section. It's here from our main website and in the previous workshop, we covered all of these things like setting up the application, setting up blockchain wallets, registering new users and opening the trades.

Right now, we are gonna do a follow-up on this and we are gonna create fiat currencies inside Datum and create trading pairs like Bitcoin, US dollar or Bitcoin Frank, or even you can create a trading pair for fiat to fiat. So Euro for US dollar or anything you wish. Anything is possible. So let's deep dive into the postman right now and let's take a look what we are gonna do. Last time we were covering the exchange workshop workspace and there are some sections in this workspace. We were creating customers. We were creating addresses and accounts for those customers and performing trades between those two customers.

Right now, we are gonna create more accounts with different fiat currencies for those customers and perform new trades in the fiat section. This collection is available again from the previous workshop in this guide guide and you can download it from our guide. If not so, I will definitely edit here today. So it will be available to download the whole workspace also with fiat currencies. So let's just dive into the fiat and what we are gonna do. Datum is not only the next generation infrastructure provider for blockchains, but we also have something which we call ledger. It's a centralized database inside datum cloud and in this ledger, we use terms like accounts and transactions and currencies.

Accounts is a virtual envelope inside our ledger and you can connect these ledger accounts to the blockchain addresses and perform automatic synchronization of blockchain transactions. All the blockchain stuff is going directly into the ledger accounts connected to that blockchain address. On top of that accounts and inside the ledger, you can create a virtual currency. Virtual currency is, we can imagine it as a token on Ethereum or on Tron and we define a base pair for this virtual currency. So when we want to support any fiat inside our trading platform, we will just create virtual currency for that fiat currency in the real world. So we will create a new virtual currency with a specific name.

The name must start with a VC prefix and we set a base pair for this currency. By this, we will create a new virtual currency and we will take it to the Swiss franc. On top of that, we said that not only we create the virtual currency inside our ledger, but we also create a ledger account which is pre-filled with the initial supply of these francs inside our trading platform. So let's just use the API and the response is the ledger account which is already credited with 10,000 francs. We can call it a franc because we create a virtual currency representation of the franc. We can create as much currencies as we wish. We can create something for US dollars.

I need to add there some postfix. And we just defined that the base pair for this virtual currency will be US dollar. And we create again ledger account which is credited for 10,000 US dollars. And using this mechanism, you can create as much virtual currencies inside our ledger as you want. And you can work with the other API like for creating accounts and perform transactions or opening trades with exactly the same way as you would go for Bitcoin or Ethereum or anything like this. So we created fiat currency and we can now create new account for one of our customer. From the previous workshop, we have one customer who has accounts in BTC, who has accounts in Ethereum.

We can take a look here, at least those accounts from the previous workshop. We can see that this customer has accounts with BTC and there is a BTC value. There is account for Ethereum, there is Ethereum value. Right now we can add a new account in the francs we have just created from the previous call. So let's create him a franc account, VCCHF. And we used exactly the same endpoint as for creating a Bitcoin or Ethereum account. The only difference is that we didn't assign any Xpub or blockchain representation or connection to the blockchain. So when we check endpoint for Bitcoin, we can see there's extended public key from the blockchain wallet.

But when we create account for frank, there is no such thing because this is only inside our ledger, inside our database and it has no connection to blockchain. So using these principles, we can create as many accounts for different customers as we want. And now when we list the customer accounts, we will see that there is a franc account down there and the franc account is here. Right now the balance of the account is zero because the user has no francs in the system.

So how to top up the user's account and what's the journey inside the exchange as such? Usually what you as an exchange want to do, want to provide to your customers is possibility to deposit fiat, deposit euro, deposit US dollar, deposit francs using SEPA payment or via credit card, debit card. And once you process that payment in your bank or using a PayPal or any other provider, you need to increase the balance of your user's account inside your system. So for that operation, there is a mint operation for virtual currency inside our ledger. And you can define a specific account ID on which you want to create a new balance. You want to increase the balance on that specific account of that virtual currency.

You can also add there some additional information to that transaction because this is gonna be a transaction inside our ledger. This is gonna be a mint transaction for that account. So let's say that we want to increase the balance of my customer number one and his frank account. All we need to do is we need to find the ID of that account. And we say that this guy have sent 10,000 francs into our bank. We process that money and right now we want to increase his balance inside our exchange. So let's just send him 10,000 francs into his account. Respond is always a reference to the transaction that happened on that account.

And when we take a look to the list of the transactions for that specific account, we will see the mint operation. And we can see that we minted 10,000 francs. So we credited his account with 10,000 francs. So when we check again the balance, we can see that the balance of his account is 10,000 francs. And you can do those operations can again be performed on any fiat currency. You can see that the operation is very atomic. You just enter the account ID of the account and the number of money you want to create on that account. Similar operation is when the user wants to withdraw fiat from the exchange.

He wants to send 5,000 francs using a SEPA payment or withdraw to the card, whatever. You process that request inside your system, inside your bank office. And then you want to decrease the balance of his account inside your exchange. So the opposite operation to mint is revoke where you just again enter the ID of the account from which you want to decrease the money. And we just say that this guy wanted to withdraw 5,000 francs and in the list of transactions for that account, we see that he withdraw really 5,000 francs and the balance of his account is not 10,000 but only 5,000.

So just to very quickly sum it up, we are able to create as many fiat currencies using the concept of virtual currency inside Atom. We can pack those currency to a specific like fiat pair from the real world. We can increase the supply or balance of a specific account for the virtual currency, which represents the depositing of the fiat money to the exchange. And we are able to decrease the supply which represents the withdrawal of the fiat from the exchange to the outer world. Okay, so right now we have created a frank account for this customer. Let's create a frank account for customer number two. So we will just create VC frank account for customer number two.

And we will then perform a trade between those two customers. Okay, so we can see now that customer number two has Bitcoin Ethereum and frank account, customer number one has Bitcoin Ethereum and frank account. Right now we want to create a new trading pair inside our exchange. And we want to support the fiat crypto pair Ethereum frank. So as previously we said in the previous workshop, defining the new trading pair is very simple. You just open the first trade of a specific trading pair and the trading pair is created. It's very intuitive. And right now we want to open a buy trade and a sell trade for Ethereum to frank. We know that this guy, customer number one, would like to buy 0.

005 Ethereum for price 2200 francs for the Ethereum. And the operation of a trade is buy. We need to just make sure that these accounts represents the correct accounts for Ethereum and the currency to account ID should be a correct account for the frank. So we need to alter these accounts for currency number two because we have adjusted, we have just created these accounts. So we obtain, give me a second. Okay, we obtain frank account from customer number one. And we open a buy trade. We can see now that in a history of the trades that there's open buy trade for Ethereum frank trading pair and there's zero fill. So the trade is not filled yet.

And we are waiting for any other counter trade to just match these trades together. So there is a customer number two who decided that he wants to sell his, this endpoint, who decided that he wants to sell his Ethereum for francs. He said, I'm gonna sell 2000, I'm gonna sell for 2200 francs and I'm gonna sell 0. 005 Ethereum. Again, we need to make sure that these account IDs corresponds to the trading pair we have. In case that the currencies don't fit with the pair, there's gonna be an error that there's incompatible currency for currency number two and that account ID. So we need to add there a correct account for a frank and we can perform a sell trade.

Okay, we have performed the sell trade. I think the buy trade should be closed now. There is not gonna be any open sell because those trades just match together. And in the history of the trades, we gonna see that there were two closed trades for buy and sell. So when we list accounts for customer number one, we can see that his francs got, his frank account has lower balance because he bought some Ethereum for that. And we can see for customer number two that his frank account balance increased and Ethereum decreased. So the trades got matched and we can see that the balances of the accounts are changed.

And now we can see the transactions for the frank account and we'll see that the exchange transaction and we have sell 11 francs and we would see the opposite operation that we bought 0. 005 Ethereum. These trades again, worked exactly the same way for pairs with fiat or with crypto. There is no difference between that. It doesn't matter if you enter here Ethereum or which is a crypto account or you enter here virtual currency account. It doesn't matter, it's up to you. So in your implementation, you don't have to differentiate between different types of accounts. You always invoke exactly same API calls. So that was basically it for a fiat support inside your exchange.

So right now, if you have any questions to this, feel free to shoot in the chat. If not, we will continue with the security and how to store private keys securely and how to work with that. So feel free to ask anything which wasn't clear or is interesting for you. Okay, I don't think there's questions. If there's a question, just shoot. I'll just continue with the security thing. And if there's any question regarding this, I'll just come back to it later. Okay, so this was the fiat. And now let's deep dive into the security.

We as Tatum and in our API, you are able to perform any blockchain transaction by providing the private key in the API and sending the private key to our API and to our servers. We have that functionality because for quick prototyping or playing around with the API, it's very easy and it's very convenient for you as developers to just play and you just don't mind security. Usually you are playing around on the test net and those assets are not worthy anything. But for a production, this is not a good option at all. We as a company, we don't want to receive private keys from you, we don't want to have that in our ecosystem.

But if you send us in the API something, we just use it and throw it away. That's our policy, we don't want to do anything with that. But you are compromising your private keys if you are sending it to the third party API. Because the request is traveling through different routers and it's cached and logged multiple times and you never know what can happen and who can just crack the SSL in the next couple of months or years and your private keys are just compromised. So you don't want to do that. You want to work with your private keys in your own servers, in your own perimeter and you want to store them in your system which is denied from all basically.

No one can touch your server from outside. There should be open no ports, maybe ideally. And your server should be really, really safe and secure. That's the place where you want to store your private keys or somewhere on our reward if you want. So keeping this in mind, we give you a possibility to have this kind of server and run a tool from Tatum which is open source and available on GitHub and it's called Tatum KMS. You can find the whole sources on our GitHub. It's completely open source. You can always check the implementation and what we actually do with your private keys which are stored there.

And this tool, Key Management System, is just a small command line application where you do two things. The first thing, you are generating wallets securely in your system, ideally without internet. So no one has access to that. That's the first thing. And the second thing is that you can store those generating wallets inside the KMS and run a daemon mode of the KMS which periodically checking, which is periodically checking Tatum API if there is no pending transactions to sign because in every of our API, which is doing something with private keys and assigning of the transactions, there is a possibility to add a signature ID instead of a private key or mnemonic. And the signature ID is the representation of your wallet stored in the KMS.

So to Tatum, to our API, to our cloud, there is no, we don't receive private keys in the request. We just receive some kind of ID and we cannot do anything with that ID because it's just ID of your KMS wallet in your system. We don't see anything like that. So let's jump into the command line and let's do a quick demo of a KMS. Maybe I'll just make a font bigger. So everyone will see, but I'm not sure. I'll make text bigger. Even maybe one more time. Okay, I hope it's much better now. And Tatum KMS is hosted on NPM. So you can install it using NPM install.

Ideally, if you install it globally, NPM install global under the tatumio slash tatumkms. There's a lot of questions from our community why it's not installing like these. There are some errors. Yes, if you want to install it globally and you are on a Linux or Unix system, you need to add there a pseudo because when you want to install a package globally, it must be installed under the root or with the root privileges. And when you install the KMS, there's a tatumkms command. Ideally, we can start with the help. And with the help, you can see what's the possibilities and what tatumkms offers you. The first thing is the demo. It's a demo mode, which tatumkms is a default behavior.

You just want to run a demo and this demo periodically fetches the datum API. If there is any transaction, it can sign and process from your server. But before you run a demo, you need to have your wallet or you need to have a wallet inside a KMS and the wallet has to have signature, has to have signature ID generated and connected to that. So for today, quick workshop and quick demo, we will work with Ethereum. So we would like to perform Ethereum transaction. We want to send Ethereum from one account to another, very basic operation.

Normally, when you play around, you would just enter the from private key here into the request and you would just enter the private key, send it to tatum and data processed automatically for you. But as I said, this is not good. So instead of a private key, you need to enter a signature ID. This signature ID is a hash from Tatum KMS. So let's just create a wallet inside Tatum. When you want to just generate the wallet read only, you have to invoke the generate wallet command. You entered the chain you want to work with. So we are working with Ethereum and we will work in a testnet. So we want to generate testnet keys.

The Tatum KMS will just generate a random wallet with a random mnemonic and xpop. It doesn't store anything anywhere. This is just a read only. You can do whatever you want and generate wallets as much as you wish. If you want to generate the wallet and store it inside the KMS, you need to invoke store, you need to invoke generate managed wallet command. So this is again for Ethereum, again for a testnet. And what the KMS is asking you right now is to enter a password to access a wallet store. Every time you want to store the wallet you have to enter the password to the KMS. The KMS is creating a file. The file is encoded locally on your system.

And this is the password for encryption. This is the encryption password which will be used to encrypt your data file with the private keys. So your private keys are stored on your server and encrypted on top of that. So there's no like full plain text private key not like that. And you can enter any password you wish. I have very basic one, one, two, three, four, five. So I can always remember that. And I can see that there's a XPUB the Xtami public key for the wallet and not a mnemonic as for the previous call but the signature ID. And this signature ID is the one I will use in my calls.

There is no way you can connect the signature ID to the private key or mnemonic from outside of your server and of your instance of KMS. When you want to see how much wallets you have and which wallets you have and what's the status of your file you just export the data from the KMS. And then you can see the data you just export the data from the KMS. Again, you need to enter the password and you can see that those are all wallets you have inside your wallet file. This is the last one we have just created right now. And we can see that mnemonic is available here.

This is the only way how you obtain the mnemonic and the private keys from your wallets, from your KMS. This is the only way. So we advise to do backup of your wallet file. We advise you maybe to backup your mnemonics in like a paper wallet somewhere else, always backup your private keys in a secure way. And if you are asking, where is the wallet file? The wallet file is always in your home directory. In your home directory, you will see there is a . datumrc directory and inside that there's a wallet. dat file. When we just print the content of the wallet, you can see that it's encrypted data. So you cannot do anything with that. You just cannot.

Without the password, even though the attacker, just some hacker attacks your server, he has access only to these files. Let's go back to the KMS we are working with. Okay. So we can export the content of our KMS. We can generate a managed wallet and also managed wallet or managed private key. The difference between generate and store is that generate just generates a new, generates a new random fresh wallet or private key and a store really stores mnemonic or private key which you already have, it stores existing one.

So for example, you can export your wallet from, I don't know, MetaMask or something like that and import it inside the KMS and you can work with the same, you can work with the same same wallets in a MetaMask. It's up to you. And so right now, as I explained before, I have already stored there one of my existing private keys. It's connected this signature ID 977. And right now I want to, what this 977. And right now I want to send Ethereum for this signature ID. Let's just send it. I hope I have enough money on the private key. We will see very soon. So what I'm doing, I'm sending 0.

01 Ethereum to this recipient address and it's gonna be sent from this signature ID which is connected to this private key. Let's just send it to the Ethereum. The response from the API is not the transaction ID of the blockchain, but it's a signature ID. And with this signature ID, you can see the detail of the pending transaction. You can see the, you can see the detail. This API call is wrong. And you can see what is actually stored inside Datum. And if it's already processed or not, we can see that there is some serialized transaction, some information about that. There is a signature ID of the private key we will issue. And there's Ethereum chain we are working with.

And this is the ID of the signature. And this is the ID of the signature. If you want to cancel the transaction because we don't want the KMS to process it, we will cancel the transaction again using this ID. And right now the transaction is still pending. It's pending inside Datum until the KMS will process it. So right now we have already managed keys, managed wallets inside the KMS. So we want to run a daemonmode. So for daemonmode, you need to enter datum-kms-daemon. You need to, again, we are working on a testnet. So we need to add their flag testnet. We can specify a chain, which we will be checking. By default, KMS checks every chain Datum supports.

But if you were going to be with Bitcoin or Ethereum, it's not necessary for you to check all the chains. So we can just now check the Ethereum one. And we need to enter the API key we are using for Datum. Because the Datum KMS need to ask the Datum with this API key. If there is any transaction, we should be processed. So I need to copy the API key I used to invoke this transaction. And what is happening now is daemon is starting. He wants to load your wallet file, but the wallet file is encrypted. So we need to enter the, again, the password to your wallet file.

And this is the only place where you enter the password. It's not possible to add it as a command line parameter or as an environment variable, because I can't enter the password. But you can enter it as a command line parameter or as an environment variable. Because again, if the attacker will attack the system and he will have access to your command line, he can just list the files and he will see the password there. So when you enter it here, it's a little bit more secure, not unbreakable, but a little bit more secure. So we'll just unlock the password. And right now the daemon will periodically check if there is new pending transaction for signing.

He detected that there is a pending transaction, the one we sent and the one we were checking here. And he just get it, process it. And right now we can check in the detail of the transaction if there is a transaction ID and there is one. So the KMS just signed the transaction, broadcast it to the blockchain, updated the transaction status inside datum. So this transaction which has transaction ID will not be fetched again. And we can check on the blockchain if the transaction is successful or not. I hope it is. And it is. So we have sent 0. 01 interior to the recipient from this account.

This account was connected to the private key we have stored for that signature ID inside our KMS. And the daemon mode is still running. It's still checking for new transactions, checking all the time until a new transaction arrives. So we can just send another one. Let's say we will send 0. 2 right now. And we can see that the KMS just fetches the transaction immediately and it's broadcasted to the blockchain. I hope that should be. So when we check the status of the transaction, again, we can see there is a new transaction ID and this transaction ID can be used inside the explorer. And we can see that really 0. 02 with Ethereum was just sent to the recipient.

If there is any error during the process of the signing, the error will be displayed in the command line. For example, maybe we can try to send invalid signature ID. For example, let's change D for E. And we can see that there is some error because the signature ID wasn't connected to any transaction, to any wallet inside the KMS. So every time the transaction is fetched, it cannot be processed and it's just throw away. So when you find out there's some problems inside the KMS, you need to manually delete this pending transaction from the KMS because it will be there forever trying to sign it correctly.

If you in the future will be able to generate signature ID with the correct one, transaction will be signed, but you don't wanna do that. And using the delete command, you can just delete the transaction. And you can see that the transaction is not there and you can see that the transaction is not there yet. It's just deleted from the KMS and wasn't signed and transferred to the blockchain. Okay, maybe one last thing I want to tell you and I want to show you a lot of things, a lot of developers are asking why my transaction is not signed. There is some error, there's some error about mnemonics and the addresses and stuff like that.

It's very important to know which type of wallet you are using for which type of transfer. When we check the KMS and export the data, which I have stored inside my wallet, we can see that some of the signature IDs are connected to the mnemonics and some of the signature IDs are connected to the private key. And if the request you are using for a transfer is using private key and you enter signature ID for a mnemonic, it will just not match. And on the other hand, if the request is for transfer, it's using a mnemonic and you enter signature ID for the private key, again, it will not match.

So you need to be sure that you are using the correct signature ID for a mnemonic to a mnemonic transfer. Correct signature ID connected to the private key to a private key transfer. Otherwise those things will just not match together and there will be errors inside your KMS. Okay, guys, that's it. I'm happy to answer any questions you have about this. Maybe one more thing, feel free to ask questions in the chat and one more thing I want to add to the KMS is that we do support integration of the wallet store to Azure. So inside Azure Vault, you can store the password to your wallet file.

So we don't have to enter the password manually, but the password will be obtained for Azure Vault. And the same way is for VGS, guys from very good security, it's American company, very good for security, for private keys, they have PCI, they have PCI certification for working with the cards. And you can also store private keys inside VGS, same as Azure. So you can store private keys inside your system or somewhere else, it's up to you. And if it doesn't work for you, these choices, you can just fork the source code on a GitHub and do any modification as you want. So I'm happy to answer any questions you have.

It was a lot, it was a lot of new information, a lot of new stuff. I'm pretty sure that if you want to play around with that, you will just go through the workshop one more time and just do it by yourself or all the things. And the only way how to be familiar with that is just to really play around and test the KMS, test the integration and see what's working and what's not working. Okay, so I don't see any question here. If you have any questions, you can, you feel free to join our workshop. So thank you for your time today. I hope you liked this session. If you have any questions, please feel free to ask me.

I'll answer them in the chat. So if you have any questions, please feel free to ask me. I'll answer them in the chat. So thank you for your time today. Feel free to join our Telegram group or we are also on Reddit. Telegram group is Tatum. io. So you can join here or feel free to write email, ask on Reddit. And as I said, the video will be available, I hope later today on our YouTube channel. It's again, Tatum. io, I hope. And the video will be available in our YouTube channel. And feel free to subscribe. And there's gonna be more and more videos from the workshops. And I'm happy to, I'm happy to, to answer any questions you have.

And I'm happy to invite you to next workshop. I'm still not sure about the topic, but it will be, I think, in next Wednesday or week after that. And we will go again, we will go through another interesting stuff which can be done using Tatum or just we will deep dive into more specific things from Tatum ecosystem. So guys, thanks a lot again and enjoy the rest of the day. Thanks a lot. .

Tatum

Workshop: Crypto Exchange for Developers part #2

Opis wygenerowany przez Skrybot

Transkrypcja wygenerowana przez Skrybot

S K R Y B O T

Skrybot. 2023, Transkrypcje video z YouTube