Creating a blockchain structure using Liferay Objects
Andre Fabbro
February 20, 2024
35 Minute Read
Introduction
The Liferay platform has been used for the development of corporate applications by many companies for several years. This is because it stands out for its flexibility in extending its ready-made components, broadly meeting the needs of business applications, such as security, clustering, indexing, and internationalization.
However, directly building corporate systems on the platform can complicate future updates due to changes in the internal API. Liferay Inc. has, therefore, focused on features that allow extension to external runtimes, minimizing the impact of updates on the API. Concurrently, the platform encourages the development of low-code applications, facilitating the updating of versions.
In this context, this article aims to explore these low-code features of Liferay, demonstrating the construction of a blockchain and the mining of a fictitious cryptocurrency, RayCoin, in addition to presenting a system for managing digital wallets and transactions, highlighting Liferay's adaptability to various business needs.
Blockchain Fundamentals
Before we proceed with the implementation using Liferay, it's crucial to understand the fundamental concepts of the blockchain data structure. This structure is essentially a sequence of interconnected blocks, starting with the initial block, known as the "genesis block". Each subsequent block maintains a reference to its predecessor through a cryptographic hash, generated from the block's information and including the previous block's hash. This methodology ensures that the blockchain is a reliable and virtually immutable data structure.
The connection between consecutive blocks in the blockchain is established through a hash, which is calculated from the information contained in the block itself and incorporates the hash of the preceding block. Thus, the hash of each block is derived from a dataset that includes the current block's information along with the previous block's hash. This approach, despite its apparent simplicity, is profoundly ingenious, giving the blockchain its characteristic of being a highly secure and practically immutable data structure.
Understanding the fundamental concept of blockchain, it is essential to detail the components and attributes that make up this structure. The central element is the Block, with the following attributes:
Index: Identifies the block's position in the chain.
Header: Contains the calculated hash of the block.
Previous Hash: Refers to the hash of the preceding block, connecting it in the chain sequence.
Nonce: A unique number used to find the solution to the cryptographic problem that allows the block to be mined, adjusting to the current level of difficulty.
Transactions: A set of all transactions included in the block, detailing transfers of value between different wallet addresses.
Therefore, a block not only stores its intrinsic attributes but also encapsulates multiple transactions. These transactions, representing debit and credit movements between digital wallets, are fundamental to the immutability of the blockchain, as the hash of each block is calculated by incorporating these data. In the context of this article, in building a cryptocurrency system, blocks contain transactions involving RayCoin, evidencing transfers between digital wallets associated with this fictitious cryptocurrency.
Continuing with the detailing of the blockchain elements, each transaction within a block is defined by specific attributes that ensure its integrity and traceability:
Transaction Id: Serves as a unique identifier for each transaction, ensuring its uniqueness within the chain.
Address From: Denotes the digital wallet address from where the values will be debited, initiating the transfer of funds.
Address To: Specifies the transaction's destination, i.e., the digital wallet address where the values will be credited.
Signature: Represents the digital signature generated by the sender, essential for verifying the transaction's authenticity and authorizing the debit.
Amount: Quantifies the value of the transaction, expressed in the cryptocurrency's unit, facilitating the understanding of the transferred volume.
Status: Indicates the current condition of the transaction within the system, which can vary between states such as approved, pending, or denied, reflecting its processing and validation.
This detailed structuring of transactions not only reinforces the security and transparency of the blockchain system but also facilitates the tracking and auditing of all movements.
Finally, we address the representation of a digital wallet, a fundamental element for blockchain users, enabling the management and transaction of cryptocurrency units. The conception of a digital wallet is straightforward, encompassing essential attributes for its functionality and security:
The digital wallet is quite simple, composed of the following attributes:
Name: Informative designation of the wallet, facilitating identification by the user.
Public Key: Acts as the address for sending and receiving cryptocurrency units, functioning as a public identifier of the wallet.
Private Key: Essential for signing transactions, ensuring the authorship and security of financial movements. This is sensitive data, known exclusively to the wallet's owner.
This article proposes the construction of a blockchain composed of blocks that record transfer transactions of the cryptocurrency RayCoin between different wallet addresses. Understanding how each block is formed, through the mining process, is crucial. Traditionally, mining involves solving a complex cryptographic problem that requires significant computational effort. In most blockchain networks, the node that solves this challenge first propagates the new block to the others, initiating a consensus mechanism to validate the block's authenticity. If validated, the block is added to all participants' blockchain. Several consensus mechanisms exist, with Proof-of-Work (PoW) being one of the most well-known. For the purposes of this article, we will focus on constructing a single node of the blockchain, without the ambition of developing a complete network, and, consequently, without implementing a consensus algorithm.
The generation of blocks occurs when a defined number of transactions is reached, triggering the mining process that incorporates these transactions into the new block. This block is then added to the chain, containing its own hash, calculated from the included transactions and the previous block's hash. As part of the mining process, units of RayCoin are credited to the miner's wallet as a reward, a value also defined by the system. Thus, the blockchain grows with the continuous addition of new blocks, reflecting the received RayCoin transactions.
Project Plan
After understanding the fundamental concepts of blockchain technology, it is imperative to establish a clear strategy for project implementation. In this context, we will explore the resources and functionalities provided by the Liferay platform, which will form the basis for developing a comprehensive solution. Recognized for its robustness and adaptability, the Liferay platform offers a series of low-code tools that allow for the rapid construction and customization of applications, without compromising the complexity or security necessary for a blockchain project. Our goal is to demonstrate how these resources can be effectively used to create a functional blockchain structure, including the mining of a fictitious cryptocurrency and the management of digital wallets, leveraging the full capabilities of Liferay.
Multi-tenancy
To simulate the process of buying and selling RayCoin, the multi-tenancy functionality of Liferay will be adopted, which allows for the creation of multiple logical instances within a single physical instance. This feature is crucial for structuring the project, where two distinct instances will be configured:
RayCoin Instance: Aimed at building the blockchain itself, this instance is responsible for receiving transactions and mining the blocks, which will later be organized in the chain.
XChangeRay Instance: Designed to simulate an external service, this instance functions as a cryptocurrency exchange, where users can manage their RayCoin digital wallets and initiate transactions. The goal is to facilitate user interaction with the blockchain, allowing for the sending of transactions to the first instance in a simplified and intuitive manner.
This functionality is a cornerstone of the low-code concept offered by the platform, allowing for the creation of custom objects that represent entities for the development of customized solutions. Through Liferay Objects, the platform provides an integrated approach to all the necessary layers for the persistence of these objects in the context of business logic, including the automatic generation of an integration layer via RestFul or GraphQL protocols. The Liferay Objects framework stands out for its versatility and power, enabling a wide range of customizations and extensions.
In this project, the objects to be created to compose our blockchain solution include:
Blockchain: Object that encapsulates the main information of the blockchain.
Block: Represents the individual blocks of the chain, containing transactions, their unique hash, and the reference to the hash of the previous block.
Transaction: Used to record transactions and associate them with the corresponding blocks after mining.
Wallet: Allows users to create and manage their digital wallets, essential for signing the transactions sent to the blockchain.
Wallet Balance: Stores the balances of wallets, facilitating the consultation of balances without the need to traverse the entire block chain for transaction validation.
Implementation
After an initial understanding of the main functionalities that will support the implementation, we are ready to begin the project setup. The first step involves activating a Liferay instance in a local environment. For this article, we will use Liferay version GA109. The instance can be easily set up in a Docker environment using the following command:
docker run -it -m 8g -p 8080:8080 liferay/portal:7.4.3.109-ga109
In this project, we intend to create two logical instances in Liferay, each operating under a distinct Virtual Host, thereby allowing each instance to respond to a specific address:
RayCoin Instance: Will be the core of the Blockchain, responsible for processing transactions and mining blocks, forming the block chain.
XChangeRay Instance: Will simulate an external service, functioning as a cryptocurrency exchange, where users can manage their RayCoin digital wallets and execute transactions.
To configure the Virtual Hosts in the local environment, it is necessary to edit the /etc/hosts file (Linux) or C:/Windows/System32/Drivers/etc/hosts (Windows), including the following line:
127.0.0.1 raycoin.local xchangeray.local
This directs accesses to the addresses http://raycoin.local:8080/ or http://xchangeray.local:8080/ to http://localhost:8080/, allowing the running Liferay physical instance to recognize and load the appropriate logical instance based on the accessed Virtual Host. With Liferay active, accessing http://raycoin.local:8080/, the main instance will be loaded. After logging into this instance, navigate to Control Panel -> Virtual Instances, and in the instance with Web Id equal to "liferay.com", edit the Virtual Host to include "raycoin.local".
Next, proceed with creating a new virtual instance, entering the necessary information:
Web Id: xchangeray
Virtual Host: xchangeray.local
Mail Domain: liferay.com
Virtual Instance Initializer: Blank Site
XChangeRay Instance
Wallet Object
After creating the new instance, access http://xchangeray.local:8080/ and log in as an administrator, then go to the menu Control Panel -> Objects to create the first object. Access the option to add a new custom object (button '+') and include the Wallet object information:
Label: Wallet
Plural Label: Wallets
When creating a new Object in Liferay, we are essentially defining the records that will compose this Object. Initially, Liferay keeps these definitions in a draft state, allowing adjustments and refinements until the user finalizes the settings and opts to publish the Object.
Upon accessing the panel of the newly created Object, a range of tabs becomes available for exploration: Details, Fields, Relationships, Layouts, Actions, Views, Validations, and State Manager. Each of these tabs unlocks distinct features, offering substantial flexibility for composing complex solutions. For example, in the Fields tab, it's possible to create custom fields that specifically align with the business logic of the application. This level of customization emphasizes the power and versatility of the Objects framework within Liferay.
To create a custom field, go to the Fields tab, trigger the '+' button (Add Object Field) and fill in the field information.
Therefore, for this Wallet object, create the following custom fields:
Label
Field Name
Type
Mandatory
Name
name
Text
Yes
Private Key
privateKey
Long Text
No
Public Key
publicKey
Long Text
No
When defining custom fields for the Wallet object, it becomes essential to establish a logic for the automatic generation of public and private keys every time a new Wallet is created. This functionality is managed by the "Actions" tab of the object, allowing the insertion of business logics at different stages of the object's lifecycle, such as its creation or update.
Specifically for the Wallet object, it is necessary to generate a new private key and a public key at the act of creating the object. For this, go to the "Actions" tab, trigger the "Add Object Action" button, filling in the "Action Label" field with "SetKeys".
Navigate to the "Action Builder" tab. Here, we define the logic to be executed, choose "On After Add" in the "Trigger" option so that the action occurs immediately after creating a new record.
Select the "Groovy Script" option for the "Action" section. This Groovy script, leveraging the available attributes of the object, executes the desired logic, including the generation of keys.
Upon selecting "Groovy Script," note that a field opens up for including the script.
To generate the keys, we will implement in this script a class named Wallet, as below:
With this class, when a new Wallet object is created, the method generateKeyPair() will automatically be called, generating the KeyPair using classes from the java.security package. Then, the methods getPrivateKey() and getPublicKey() will return the private and public keys, respectively, already in string format, to be stored in the corresponding fields of the object.
To store the keys in the object, we will use the updateObjectEntry() method from the ObjectEntryLocalServiceUtil class of Liferay's Objects API. The code should be as follows:
From this code, it's observable that the object fields can be passed through a Map, in this case, entryValues, where we include the public and private keys for the object with the id that is in the context (variable id). The final script should be as follows:
Copy the code and add it to the script field, and then after saving, you will notice that the new Action has been included in the Wallet object.
Next, go to the Details tab and change the following fields:
Entry Title Field: Name
Panel Link: Custom Apps
Disable the "Enable Categorization of Object entries" option, and then click the "Publish" button. This will publish the object. Note that Liferay already creates a default view of the object in the Applications -> Custom Apps menu option, as selected in the Details tab of the object.
Upon entering this option, click the "Add Wallet" button.
Fill in a name, leave the Private Key and Public Key fields empty, and click the "Save" button.
Note that when adding a new record, the Groovy script code is triggered, generating the public and private keys for the Wallet.
Now let's add the wallets widget so that site users can create their own wallets. For this, go to the main site of XChangeRay and add a new page called "My Wallets" through the Site Builder -> Pages menu.
Next, in the page editing screen, select the "Widgets" tab from the left sidebar, go to the "Objects" category, and add the Wallets widget to the page.
Now, to make the page visible to site users, go to the "Permissions" option of the "My Wallets" page and remove the "View" permission for "Guest" users, then add the "View" permission for "User".
This way, only registered site users can view this page. Now, it is still necessary to add permission for authenticated users to create their own wallets. For this, go to the Control Panel -> Roles menu, select the "Users" option. Next, select the "Define Permissions" tab, search for "Wallets", and select the "View" permission under the "Application Permissions" category and "Add Object Entry" under "Resource Permissions", then click "Save".
When creating digital wallets in Liferay, the platform automatically links each wallet to its corresponding user, ensuring that only the owner can view and manage their wallets. This access control is an integrated functionality of Liferay's Objects, significantly simplifying permission management.
Try creating a new user and access the "My Wallets" page to add digital wallets. You will observe that, when creating a new wallet, it is exclusively associated with the creating user, reinforcing security and privacy. If a second user is added to the system, they will not have visibility or access to the first user's wallets. Thus, each user maintains complete control over their own wallets, being able to create, edit, and remove records as needed, without interference or visibility from other users.
This method of direct association between users and their digital wallets highlights Liferay's approach to data security and customizing the user experience, facilitating the implementation of complex functionalities intuitively and securely.
Transaction Object
After creating the Wallet object, the next step is to establish the Transaction object, which consolidates the execution of transactions of RayCoin units from one wallet to another. This process will allow the user to select one of their wallets for debit and specify the recipient wallet's address for credit. To facilitate this operation, we will create a new object named "Transaction". It is important to note that the recipient wallet may not belong to the user conducting the transaction.
To add a layer of security and authentication to the transactions, we will implement a Groovy script within the "Actions" tab of the Transaction object. This script will be responsible for digitally signing the transaction using the private key of the wallet selected by the user. After the signature, the transaction will be sent to another Liferay instance via the Restful API, ensuring the integrity and truthfulness of the operation.
Therefore, select the option to create a new object called Transaction. Add the following custom fields to this object:
Label
Field Name
Type
Mandatory
To Address
toAddress
Long Text
Yes
Amount
amount
Precision Decimal
Yes
Signature
signature
Long Text
No
Next, we will link the Transaction object to the Wallet object, so that the user can select from which wallet they wish to have their RayCoins debited. Select the "Relationships" tab, then "Add Object Relationship," and fill in with the following information:
Label: Wallet
Name: wallet
Type: One to Many
One Record Of: Wallet
Many Records Of: Transaction
Note that upon saving, a new field named Wallet will appear in the "Fields" tab. Edit this field to set the "Mandatory" option to true, which will require the user to select a source wallet when creating a new transaction.
Next, select the "Actions" tab and add a new action named "Process Transaction," select the trigger type "On After Add" and action type "Groovy Script" as was done during the creation of the Wallet object. In this script, we first create a Wallet class that retrieves a wallet from the "walletId" parameter and stores the public and private keys, as below:
This class is designed to encapsulate the details of a transaction, receiving in its constructor essential parameters for executing a RayCoins transfer:
toAddress: The destination address where the RayCoins will be credited.
amount: The quantity of RayCoins to be transferred.
wallet: The source wallet from where the RayCoins will be debited.
The sign() method is responsible for implementing the necessary logic to sign the transaction. It uses the private key of the source wallet, based on the transactionData, which compiles the essential data of the transaction: the source address, destination address, and the amount to be transferred. This approach ensures the authenticity of the transaction by encrypting the data with the private key of the source wallet.
After generating the signature, it's crucial to incorporate it into the previously retrieved Transaction object:
// Create Wallet and Transaction objects
Wallet wallet = new Wallet(r_wallet_c_walletId)
Transaction transaction = new Transaction(toAddress, amount, wallet)
// Sign the transaction
transaction.sign()
// Update the object entry with the new signature
def userId = Long.valueOf(creator)
ObjectEntryLocalServiceUtil.updateObjectEntry(userId, id, [signature: transaction.signature], new ServiceContext())
Note that there are variables corresponding to the Object fields that are made available in the context of the script, such as r_wallet_c_walletId, which corresponds to the identifier of the Wallet object selected by the user for the transaction creation. This field is used by the Wallet class to retrieve the related record and then retrieve the privateKey that will be used in generating the signature. This signature will also be validated by the raycoin instance when it is sent. At the end of the algorithm, the ObjectEntryLocalServiceUtil class is used to store the signature in the corresponding field of the created object.
After saving the script, select the Details tab, choose "Custom Apps" in the "Panel Link" option, disable the "Enable Categorization of Object entries" option, and then publish the object. Note that the Transactions option will now be available in the Applications -> Custom Apps menu.
Add a new Transaction and see that the Signature field will be automatically generated.
Similar to the process of creating the Wallet object, it is necessary to add a new page called "My Transactions" on the XChangeRay site. This step includes configuring appropriate permissions for the User Role, allowing the addition of new entries. Subsequently, the Transactions widget should be incorporated into the new page, analogous to what was done on the "My Wallets" page. This way, users will be able to enter their transactions directly.
Up to now, transactions created on the XChangeRay instance are not sent to the Blockchain (RayCoin) instance, due to the absence of the necessary objects in the other instance. However, it is possible to anticipate and prepare the code for sending transactions. This is done by editing the Groovy script of the Transactions object, incorporating the sendToBlockchain(postUrl) method into the Transaction class:
This method performs a POST request to the specified endpoint in "postUrl," which will correspond to the Transaction object's endpoint in the RayCoin instance. This endpoint, which will be detailed in subsequent sections of this article, is anticipated as: "http://raycoin.local:8080/o/c/transactions/". Therefore, at the beginning of the script, include the call to the sendToBlockchain method, passing the URL of the endpoint:
After setting up the XChangeRay instance with its objects, it's time to turn our attention to the main instance, RayCoin, to configure the objects that will form the backbone of our business logic. Access the URL http://raycoin.local:8080/ and log in as an administrator. In the Control Panel, find and select the "Objects" option to start creating the necessary objects for this instance. The objects and their fields should be configured as follows:
Block:
Label
Field Name
Type
Mandatory
Index
index
Integer
Yes
Previous Hash
previousHash
Long Text
Yes
Nounce
nounce
Integer
Yes
Transaction:
Label
Field Name
Type
Mandatory
From Address
fromAddress
Long Text
Yes
To Address
toAddress
Long Text
Yes
Amount
amount
Precision Decimal
Yes
Signature
signature
Long Text
Yes
Signature Valid
signatureValid
Boolean
No
Wallet Balance:
Label
Field Name
Type
Mandatory
Address
address
Long Text
Yes
Balance
balance
Precision Decimal
Yes
Blockchain:
Label
Field Name
Type
Mandatory
Name
name
Text
Yes
Max Pending Transactions
maxPendingTransactions
Integer
Yes
Reward Address
rewardAddress
Long Text
Yes
Reward Value
rewardValue
Precision Decimal
Yes
Authorization
authorization
Long Text
Yes
Blockchain URL
BlockchainURL
Text
Yes
For each object created, access the "Details" tab, adjust the "Custom Apps" value in the "Panel Link" option, disable "Enable Categorization of Object entries," and finally, publish the object by clicking on "Publish".
Relationships
After establishing the objects, it's necessary to configure the relationships between them, simulating the links of a database. In Liferay, these relationships can be many-to-many or one-to-many. For our application, a Blockchain object will contain multiple Blocks, and each Block, in turn, will house multiple Transactions. To configure these relationships, edit the Transaction object, select the "Relationships" tab, and add a new relationship with the information:
Label: Block
Name: block
Type: One to Many
One Record Of: Block
Many Records Of: Transaction
Go back to the "Fields" tab and note that a new field named "Block" has been created, with the type "Relationship". As transactions initially do not belong to any block when they are recorded, this field does not need to be mandatory.
Now go to the Block object's editing screen, navigate to the "Relationships" tab, and you will see that the relationship created in the Transaction object also appears on this screen.
Click the "+" button to then include the relationship between the Block and the Blockchain, fill in the following information:
Label: Blockchain
Name: blockchain
Type: One to Many
One Record Of: Blockchain
Many Records Of: Block
Now in the "Fields" tab, see the "Relationship" type field named Blockchain, change this field to make it mandatory by marking the "Mandatory" field.
Access Permissions
Finally, it is crucial to set access permissions to determine which objects will be public for reading and/or writing. This setting is vital, especially to allow external systems, such as XChangeRay, to interact with the blockchain by creating Transactions and querying Blocks and Wallet Balances. Access the "Control Panel" menu, go to "Roles," select "Guest" under "Regular Roles," and in the "Define Permissions" tab, search for the term "Transactions," and check the "Add Object Entry" option in the "TRANSACTIONS" category and "View" in the "TRANSACTION" category, both under "RESOURCE PERMISSIONS".
After saving, search for the term "Blocks" and select only the "View" option in the "BLOCK" category also under "RESOURCE PERMISSIONS".
Next, do the same procedure for "Wallets Balances," marking only the "View" option.
Initial Objects Data
After creating the objects, their relationships, and access control through the permission system, we have obtained the fundamental structure of the Blockchain. Let's now create the first records of these Objects, which will serve as the basis for the next data that will be received by the API.
Navigate to "Applications" and choose "Custom Apps," select "Blockchains," and use the "+" button to add a new record. Fill in the information as follows:
Authorization: Use for authentication in calls to the Liferay RestFul API for non-public methods. For example, to check the need for mining after a transaction. Use "Basic" authentication by converting the username and password to base64. For example, for the user 'test@liferay.com' with password 'test', the value will be "Basic dGVzdEBsaWZlcmF5LmNvbTp0ZXN0".
BlockchainURL: Enter the endpoint of the RayCoin instance, such as "http://raycoin.local:8080".
Max Pending Transactions: Define the number of pending transactions required to start the mining process, for example, "3".
Reward Address: Use the public key of a wallet generated for the miner, for example, the public key can be "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEKutm5pE/nTelGk9p2mk9HpULdy3ID2tWTx/2O+D65dsAzA1MQNSdfF6RwGnCZfik++V6trwdCPTmomz0rWD73g==".
Reward Value: Set the mining reward value, such as "10".
After saving this record, proceed to the "Blocks" object and add the initial block, the genesis block, with the following information:
Hash: Use "0" for the initial hash.
Index: Position "0" for the first block.
Nonce: Value "0", indicative of being the genesis.
Previous Hash: Enter "none," since it is the first block.
Blockchain: Select the previously created "RayCoin" option.
Having done that, let's now create a record for "Transaction," representing the initial transaction with an allocation of 500,000 RayCoins to a specific wallet, let's use the following wallet in this example:
Public Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8QK/c9ZSIcVMN8HYfPcZ2cW/CXfN7c8hqFdazgE1lsFmes8UeIVovMgivL2qyeZAOuECrE8eg7HixuYcwhNFOw==
For this, create a new record in "Transactions" with the following attributes:
Amount: 500000
From Address: none
Block: 0
Signature: 0
To Address: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8QK/c9ZSIcVMN8HYfPcZ2cW/CXfN7c8hqFdazgE1lsFmes8UeIVovMgivL2qyeZAOuECrE8eg7HixuYcwhNFOw==
Object Actions
After establishing the fundamental structure and initial records, we are ready to integrate essential business logic through scripts associated with the "Actions" functionality of the objects. For each type of object involved, we will develop four scripts, detailed below:
Blockchain Object:
Mine Pending Transactions: This action, configured as standalone in the Blockchain object, diverges from actions linked to the object's lifecycle, such as the one implemented for the Wallet object in XChangeRay. Instead, this action becomes available for activation via API. Its primary function is to check if the number of pending transactions is sufficient to initiate a mining process. If affirmative, it proceeds to mine a new block that, once validated, is added to the blockchain.
Compute Balances: Also a standalone action in the Blockchain object, aimed at updating the Wallet Balance object records. It calculates the balance of each wallet, aggregating this data to facilitate future balance queries.
Transaction Object:
Validate Transaction: This action is triggered when a new Transaction is created. Its purpose is to validate the transaction's signature and verify if the originating wallet has sufficient funds to carry out the transaction.
Trigger Blockchain: This action, also triggered upon the creation of a new Transaction, aims to activate the Mine Pending Transactions method of the Blockchain object. This method assesses whether it is the appropriate moment to start the mining process.
Validate Transaction
To begin implementing the "Validate Transaction" functionality, go to the "Objects" section in the Control Panel, navigate to "Object -> Objects," select the "Transaction" object and proceed to the "Actions" tab. Add a new action named "Validate Transaction." In the "Action Builder" interface, choose "On After Add" in "Trigger" and select "Groovy Script" in "Action" to start drafting the script.
Initially, we will create a class called TransactionValidator, incorporating attributes that mirror those of the "Transaction" object, in addition to support attributes. The initial structure of the class will be:
Next, we will develop a method within this class to validate the signature associated with the object, using classes from the java.security package, available in the JVM. This process is similar to the one used for generating public and private keys and signing in the XChangeRay instance. However, in this context, we focus on validation:
void validateSignature() throws Exception {
if (this.fromAddress == 'none') {
return
}
byte[] signatureBytes = Base64.getDecoder().decode(this.signature)
if (signatureBytes == null || signatureBytes.length == 0) {
throw new RuntimeException("No signature found in this transaction")
}
def keyFactory = KeyFactory.getInstance("EC")
def publicKeySpec = new X509EncodedKeySpec(Base64.decoder.decode(this.fromAddress))
def publicKey = keyFactory.generatePublic(publicKeySpec)
def signatureInstance = Signature.getInstance("SHA256withECDSA")
signatureInstance.initVerify(publicKey)
signatureInstance.update(this.transactionData.bytes)
if(!signatureInstance.verify(signatureBytes)) {
throw new Exception("Signature validation failed")
}
}
Then, we will develop a method to verify if the originating wallet has a sufficient balance for the transaction. This process requires querying the "Wallet Balance" object to access the balances processed by the blockchain. We will use the "Blockchain" object identifier to find the appropriate address for the HTTP call, retrieving the URL of the RayCoin instance and completing it with the specific endpoint for the "Wallet Balances" API.
First, it's necessary to access the information contained in the "Blockchain" object, which stores the RayCoin instance URL. This is done through the ObjectDefinitionLocalServiceUtil class, allowing the retrieval of the "Blockchain" object definition identifier with the following code:
With this identifier in hand, we access all records of the "Blockchain" type and select the first one, considering the existence of only one record of this type:
However, this value represents only the beginning of the endpoint. To complete it, it's necessary to add the specific path of the API that manages the "Wallet Balance" objects, resulting in /o/c/walletbalances. To discover the available endpoints for each object created on the Liferay platform, the platform offers an API catalog accessible at /o/api/. By visiting http://raycoin.local:8080/o/api/, it's possible to explore and select the desired object, thus obtaining detailed information about the available endpoints.
This Liferay feature is extremely powerful as it allows the platform to be manipulated in a consistent and flexible manner, enabling both read and write operations, and also allowing the application of filters, sorting, searching, among other features. With this, developers can create remote applications in any technology and use the API as part of their business rules.
Therefore, to validate the balance, the script should contain a GET call to the "Wallet Balance" object endpoint, using a filter by the "Address" field to identify the balance of the originating wallet. The result of this call is processed to verify the availability of sufficient funds for the transaction:
After the execution of the call, if the wallet does not have sufficient funds, an exception will be thrown, indicating insufficient balance. This process ensures that only valid transactions are processed on the blockchain:
JsonArray walletBalancesJsonArray = getResponseJson.getJsonArray("items")
if(walletBalancesJsonArray.empty) {
throw new Exception("Wallet doesn't have enough funds")
} else {
JsonObject walletBalance = walletBalancesJsonArray.getJsonObject(0)
def balance = new BigDecimal(walletBalance.getJsonNumber("balance").toString())
if(amount > balance) {
throw new Exception("Wallet doesn't have enough funds")
}
}
It is now also necessary to create a method to update the transaction status. We will use the "status" field, a standard attribute in all object definitions in Liferay. It's important to recognize that changing the status should occur after the record creation, as by default, all objects are initially marked as "APPROVED" in the absence of a defined workflow. To simplify and avoid the complexity of introducing a workflow process, we opt to modify the status asynchronously, with a delay of three seconds after including the record in the system. The implementation of this method is described below:
void updateTransactionStatus(userId, id, status) {
Thread.start {
sleep(3000) // Sleep for 3 seconds
ObjectEntryLocalServiceUtil.updateStatus(userId, id, status, new ServiceContext())
}
}
With the TransactionValidator class now complete with all necessary methods, we can proceed with the transaction validation logic as follows:
Transaction Origin Validation: Initially, we check if the source address is 'none', which would indicate a reward transaction, exempting it from validations.
Creation of the TransactionValidator Object: Next, we instantiate the TransactionValidator object, filling its essential attributes with the transaction data.
Validation Process: Within a try-catch block, we perform the signature validation and wallet balance check. If both validations are successful, we update the transaction status to 'PENDING'. If any validation fails, the status is changed to 'DENIED'.
try {
// first, set the signatureValid to false
ObjectEntryLocalServiceUtil.updateObjectEntry(userId, id, [signatureValid: false], new ServiceContext())
// then, validate the signature
transactionValidator.validateSignature()
// set the signatureValid to true
ObjectEntryLocalServiceUtil.updateObjectEntry(userId, id, [signatureValid: true], new ServiceContext())
// validate if the wallet has enough funds for this transaction
transactionValidator.validateBalance()
// set the transaction status to pending
transactionValidator.updateTransactionStatus(userId, id, WorkflowConstants.STATUS_PENDING)
} catch (Exception e) {
// as the signature wasn't validated or the wallet doesn't have funds, set the status to denied
transactionValidator.updateTransactionStatus(userId, id, WorkflowConstants.STATUS_DENIED)
}
Within the same "Transaction" object, add a new Action titled "Trigger Blockchain," setting it up with the type "On After Add" and selecting "Groovy Script" as the Action type. This Action will introduce the logic that, with every new transaction received by the API, will trigger the "Mine Pending Transactions" action on the "Blockchain" object, which will be detailed later.
Initially, the action will check if the transaction's originating address is 'none', indicating a reward transaction that does not require further processing:
if(fromAddress == 'none') return
Next, the script retrieves information from the "Blockchain" object to access the instance's URL and the value of the "Authorization" attribute, necessary for authentication in HTTP calls, given that the "Blockchain" object has access restrictions:
Considering that the action on the "Blockchain" object will be of the "standalone" type, the API call will use the PUT method. The call's URL is constructed by concatenating the blockchain's URL with the specific API endpoint to trigger the standalone action:
To ensure that the call is executed asynchronously and after the successful inclusion of the record, the script runs within a new Thread, with an initial delay of 5 seconds:
To integrate the logic of updating balances in the Liferay blockchain, first access the Blockchain object definition through the control panel and add a new Action called "Compute Balances". In this context, choose "Standalone" as the "Trigger" type and select "Groovy Script" as the action to be executed.
We will develop a class called BlockchainBalance, which will incorporate essential attributes such as companyId and userId, in addition to an additional parameter objectDefinitionId to record the Wallet Balance object definition ID:
class BlockchainBalance {
long companyId
long userId
long objectDefinitionId
BlockchainBalance(long companyId, long userId) {
this.companyId = companyId
this.userId = userId
this.objectDefinitionId = ObjectDefinitionLocalServiceUtil.fetchObjectDefinition(
this.companyId, "C_WalletBalance").getObjectDefinitionId()
}
}
We will implement a method removeAllBalances() to clear all balance records, preparing the system for a balance update based on Blockchain transactions:
The computeBalance() method will be responsible for first clearing existing balances and then calculating and recording updated balances based on approved transactions. This includes initializing the 'none' wallet with a significant balance for reward distribution and updating balances according to processed transactions:
To effectively implement block mining and its inclusion in the blockchain, we will add a new action to the Blockchain object called "Mine Pending Transactions". This action will be of the "Standalone" type and will use "Groovy Script" as its execution method.
Within the script, we initially retrieve all transactions with 'PENDING' status:
We check if the number of pending transactions exceeds the limit defined in the maxPendingTransactions attribute of the Blockchain object. If so, we proceed to mine a new block:
Thus, the Blockchain class can start with the following attributes:
class Blockchain {
long companyId
long userId
long blockchainId
String rewardAddress
BigDecimal rewardValue
List pendingTransactions
String authorization
String blockchainURL
}
We will also need two other support classes, to handle blocks and transactions, therefore we create a Block class:
class Block {
long blockchainId
int index
String timestamp
List transactions
String previousHash
String hash
int nonce
}
And also a Transaction class:
class Transaction {
Long id
String fromAddress
String toAddress
BigDecimal amount
String signature
}
In this Transaction class, we will add methods to return the transaction data in the format as we have used in other classes, in addition to the methods toJson(), toJsonArray(), and toString(), which we will use as the basis for calculating the Block Hash:
The mineBlock() method is essential for the block mining process in the blockchain, determined by the difficulty parameter, an integer that defines the complexity of the task. The higher the difficulty value, the greater the computational effort required to find a valid hash for the block, based on the combination of various elements like the block index, timestamp, the list of transactions, the previous block's hash, and the nonce (an attempt counter). The goal is to generate a hash that starts with a specific sequence of zeros, meeting the established difficulty criterion. This mechanism, although simplified in this example using the MD5 algorithm for hash generation, illustrates the fundamental concept behind mining in blockchains. In more advanced implementations, more complex cryptographic algorithms and mathematical problems are used to enhance the security and integrity of the chain. However, a simplified approach was chosen in this case to facilitate understanding and demonstration of the mining process.
Returning to the Blockchain class, we will implement a utility method for making RestFul API calls:
It is still necessary to have two other methods, one to retrieve the latest block in the chain, and another to retrieve a block from its Previous Hash attribute:
After that, we will implement the final method, called minePendingTransactions(), which will be responsible for implementing the entire business logic. We create an internal list of Transactions to receive the values from the list of pending transactions. Next, we create a reward transaction, save this transaction in the database, and also add it to the same list:
void minePendingTransactions() {
List transactions = new ArrayList()
pendingTransactions.each { pt ->
if(pt.getValues().get("signatureValid") == true) {
transactions << new Transaction(
pt.getValues().get("fromAddress"),
pt.getValues().get("toAddress"),
pt.getValues().get("amount"),
pt.getValues().get("signature"),
pt.objectEntryId)
}
}
def rewardTransaction = new Transaction("none", rewardAddress, rewardValue)
rewardTransaction.save(companyId, userId)
transactions << rewardTransaction
Then retrieve the Hash of the last block in the chain, as well as its index, to increment it and use it as a parameter in the block we need to create:
To ensure that the transactions are not processed by another mining process, which may occur in parallel, we will change the status of all transactions to 'SCHEDULED':
transactions.each { t ->
t.updateStatus(userId, WorkflowConstants.STATUS_SCHEDULED)
}
Next, we can create the new block and then execute the method for mining, using a difficulty level of 2, meaning the generated hash must contain two zeros at the beginning:
def block = new Block(index, new Date().toString(), transactions, previousHash, blockchainId)
def difficulty = 2
block.mineBlock(difficulty)
After the mining process, we check if another block that was mined before this one and placed in the same position exists, if there is, we must abandon the mining, deleting the reward transaction, and returning the status of the transactions to 'PENDING':
To efficiently manage and update the balances of the wallets involved in the transactions within the block mining process, we will implement the following logic using a HashMap. This map will store the current balances of all wallets impacted by the transactions, facilitating the validation of sufficient funds and the correct association to the mined block. Each transaction will be individually assessed to determine if the originating wallet has sufficient funds for the transaction. Otherwise, the status of the transaction will be marked as 'DENIED'. Approved transactions will receive the status 'APPROVED':
After the successful completion of the mining process and transaction validation, we will update the reward transaction's status to 'APPROVED' and associate it with the mined block. To ensure data consistency and avoid potential execution conflicts, updating the wallet balances will be performed asynchronously, with a brief delay:
With the setup of the necessary actions complete, it is now possible to start creating new transactions using the XChangeRay instance. But first, go to the Blockchain in Applications -> Custom Apps -> Blockchain menu and execute the Compute Balances method from the Blockchain record in order to compute the initial balance of the wallets.
After this, create some wallets and transactions from the XChangeRay instance. This process will allow the direct observation of how transactions are processed and integrated into the RayCoin instance. It is recommended to start with the "XChangeRay Wallet" as it initially holds a significant amount of coins, facilitating the execution of test transactions. Thus, create some wallets and transactions in this instance.
It is also possible to follow the blocks records.
And also the wallet balances through the Wallet Balances object.
For those who prefer a more direct approach and want to try the demo showcased in this article without going through the whole configuration process, it is feasible to start an instance of Liferay version 7.4.3.109-ga109, connect it to a local MySQL database, and import the DUMP available at: https://github.com/andrefabbro/blockchain-demo/tree/main/mysql-dump
This DUMP includes all the object definitions, scripts, and sample data necessary to simulate the blockchain described in this article, providing an efficient way to visualize the application in action.
Conclusion
The popularity of blockchain, initially spurred by the cryptocurrency market, barely scratches the surface of its disruptive potential. Beyond the realm of digital currencies, blockchain has a wide array of applications in various sectors, from smart contracts, supply chains, and logistics, to real estate registry, digital identity, and electronic voting. These applications underscore the innovative capability of blockchain to offer robust solutions for traditional challenges, transforming processes in a myriad of industries.
While this article focused on exploring the development of a blockchain utilizing the native functionalities of Liferay, specifically through Objects, it is important to highlight that the Liferay platform is equipped with other tools and extensions, such as Client Extensions (available at: https://learn.liferay.com/w/dxp/building-applications/client-extensions), enabling the implementation of additional business logics. Therefore, Liferay presents itself as a versatile and powerful platform, capable of supporting the development of complex solutions, allowing developers to concentrate their efforts on the specific requirements of each business.
This article aims not only to demonstrate the applicability of blockchain technology in diverse contexts but also to emphasize the flexibility of Liferay as a development tool. The possibilities are broad and promising, paving the way for innovations that can reshape the fabric of various sectors, enhancing efficiency, transparency, and security.
This website uses cookies and similar tools, some of which are provided by third parties (together “tools”). These tools enable us and the third parties to access and record certain user-related and activity data and to track your interactions with this website. These tools and the informationcollected are used to operate and secure this website, enhance performance, enable certain website features and functionality, analyze and improve website performance, and personalize user experience.
If you click “Accept All”, you allow the deployment of all these tools and collection of the information by us and the third parties for all these purposes.
If you click “Decline All” your IP address and other information may still be collected but only by tools (including third party tools) that are necessary to operate, secure and enable default website features and functionalities. Review and change your preferences by clicking the “Configurations” at any time.
