## 5 Research Challenges
Ethereum is a generic blockchain platform, which is publicly available, whereas Corda is a specialized distributed ledger platform aimed specifically at the financial industry [13]. While the article does not specifically compare the performance of different blockchains to one another, rather highlighting their functionalities, similarities, and features [13], it cannot be stressed enough that Corda is run on private networks. While the performance of Ethereum and Corda networks can vary depending on the specific use case and network configuration, there are key differences in performance that can be derived from their approaches to blockchain. Ethereum is a public blockchain that uses a proof-of-work consensus algorithm, which can result in slower transaction times and higher transaction fees compared to private blockchains. Ethereum's network can also become congested during periods of high usage, which can further impact performance. Corda, on the other hand, is a permissioned blockchain that uses a unique consensus algorithm called \"notary services\" to achieve finality of transactions. This allows Corda to achieve high throughput and low latency, making it well suited for enterprise use cases. In general, Corda may offer better performance and scalability for enterprise use cases, while Ethereum may be more suitable for public and decentralized applications. However, the specific performance of each network will depend on factors such as network configuration, number of nodes, and the complexity of the smart contracts or transactions being executed. Without a thorough benchmark, it is hard to tell which network offers the better performance. What that means for blockchain developers is that the choice of which network to use does not heavily rely on performance, but rather on types of features offered, implementation of smart contracts, programming language used, currency or other elements that supersede performance concerns. In terms of architecture, the biggest challenges stem from semantic web applications, perhaps because there are far fewer applications that implement the semantic web by comparison to blockchain. However, a model architecture for the semantic web was proposed by [PERSON] and [PERSON] [14]. The proposed solution uses annotation software to generate RDF markups describing the content of the website [14]. The extracted RDF content is stored in a database and it forms part of the semantic middleware application [14]. User requests are passed to web agents which formulate a query plan [14]. RDF annotations start with namespace declarations, which act like a prefix to associate individual resources with a schema, doubling not only as a representation of data but also acting as a markup language for the ontology [14]. A reasoner is used to read the ontology model and derive knowledge about the domain [14]. Resources are queried using a multiagent architecture, with Jena as middleware [14]. This architecture model, which predates linked data, helps illustrate a view of the web where the application owner services, primarily, the machine-learning algorithms and less so the end user. Even after the creation of linked data, however, there are still numerous architectural challenges to implementing the semantic web, as described by [PERSON] et al. [PERSON]. Amongst these challenges is the quality of data fed into the semantic web. Not only is trustworthiness an issue, but so are formatting problems and querying issues [15]. Then, there is the issue of the data complexity itself. Even using some of the proposed guidelines for selecting vocabulary or ontology for correctly describing the data is a very long and time-consuming task requiring supervision by a human expert [15]. The purpose of the semantic web is, primarily, to obtain the meaning contained by data in such a way that computers understand it, but web information does not have a heterogenous structure and making data associations with a pre-set vocabulary is not easy [15].