Instantiating The Contract Object (Server-Side)
Passport can create an interface to a contract through a built-in object relational mapper. Leveraging the ethers library, Passport is able to map the contract to the blockchain based on the contract schema (known as a “Application Bytecode Interface” or ABI) service coupled with a blockchain address for the contract to create a JavaScript object as if it were on the local device.
If you are familiar with blockchain development, you may be aware that we need a “Web3 provider” (the blockchain equivalent of a database ODBC connection) to be configured. Fortunately, Passport has a provider built in that can be used for exactly this.
While Credenza will provide a helper library to abstract the construction of a Blockchain contract, it is useful to see the steps that are required to instantiate a contract in case there is a plan to optimize our use other non-traditional JavaScript libraries for accessing the Blockchain.
Below is an example of a contract and the code that is required to map and block change my contract to a JavaScript object.
For those familiar with Passport v2, this is a significant change as Credenza has created a helper library ("@credenza-web3/contracts-lib") to create easy access to blockchain contract metadata and instantiate a contract with one line of code. Now, it only takes one line of code to build a tunnel into a Credenza smart contract. The parameters will specify the source, type, and location of the contract and the subsequent variable (contract) is now a full object with all methods accessible through simple JavaScript calls.
Instantiating The Contract Object (Client-side)
The process is similar on the client-side, except it will be the fan that needs to provide the wallet instead of the client. Therefore, there are no private keys (Passport handles that) and you do not need to identify a provide (Passport does that as well). Again, sharing the client-side version of code construction you saw in the previous section, we would request the provide from Passport, and then the signer (a mix of the provider and the private key as generated securely by Passport) can be retrieved using getSigner. With that, the signer can be used to generate the contract object that will be called to access the contract functionality.
Calling Contracts
Calling a contract doesn’t necessarily require an identity, but with the contract create it, you will get access to any read or write function that is permitted by the Smart contract. In the code below, the credenza royalty contract is going to be called to do a point check on a LoyaltyContract type contract at address contractAddressLoyalty for user 0x375fa2f7fec390872a04f9c147c943eb8e48c43d.
In this code, the value of points is written to the pts variable and you can imagine writing some logic for your application that relies on this value. Our example merely uses the value to write to the console. Note that “toString()” is used. That is because values returned from the blockchain are of type BigNumber, which acts differently in blockchain and a conversation is required to make it readable for our console.
Writing into a contract is similar to reading. Again, you will retrieve a contract object, and then call the method to perform the blockchain permutation. Remember that read actions are free, but write actions cost “gas” (either ETH or MATIC, depending whether you are on Ethereum or Polygon). Your gas fees will depend on your agreement with credenza, so make sure there is sufficient funds available for each write. The code below will simply add 42 points to the account of 0x375fa2f7fec390872a04f9c147c943eb8e48c43d.
The appendices highlight specific programmability of Credenza smart contracts and specific required to instantiate contracts and access methods to retrieve or modify data held in them.