Which concept is used for creating a transaction chain in Corda? Is the chain formed is based on Directed Acyclic Graph (DAG) or any other chaining concept. In Corda, there is no concept of the single-chain using genesis block
Corda makes use of the UTXO model. The key concepts section contains a good introduction of how this model works in practice.
In Corda, there is no concept of the single-chain using genesis block
Correct, in Corda there can be multiple, normal transactions that contain only output states and no input states.
Related
So i was going through this paper :- http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
There in the part of replication they have mentioned that Each key k is assigned to a coordinator node. Is this coordinator node the actual physicial nodes in context of consistent hashing? Of are there some specific nodes out of physicial nodes assigned this task of being coordinator nodes.
Also they have mentioned that there are more than N nodes mentioned in preference list. However if a key is replicated to N-1 physicial nodes does this prefrence list has virtial nodes too?
I am little confused here
That 2007 paper covers "Dynamo", which is a database that came before the DynamoDB service. You can't read it to understand how DynamoDB works.
Here's a paper about DynamoDB, if you like reading conference papers instead of documentation: https://www.usenix.org/system/files/atc22-elhemali.pdf
Nebula Graph version: 3.3
I’ve been checking the source code of the NebulaGraph Database and have gotten confused about the relationship and the difference between KVStore and KVEngine. KVEngine implements RocksEngine.cpp to access rocksdb， while KVStore seems more like a logical concept, and all kinds of CRUD are executed through KVStore. So, how KVstore interacts with the underlying database?
Good question.
KVEngine is the abstract of the key-value engine per single(server) storage instance, and RocksEngine is one of its implementations.
KVStore is the abstract of the general Storage layer (as you mentioned, logical), i.e. the Distributed Consensus + KVEngine together construct the KVStore. NebulaStore is one of its implementations.
I would like to ask your help and suggestion about below use case what are related to our new business case, a CorDapp which will be used to manage software license usage and management.
Does Corda has a pre-defined structure or approach to define the parent and child relationship between different states, for example, one contract state(main contract) has two child contract states(two types of license contracts)
If we want to track the license usage on blockchain, is that a good direction to ownable state for licenses? Our current thought is Party A(License Provider) and Party B(License consumer) has one agreed contract that Party A will provide Party B 100 licenses to be used, but charge will only happen after one license is activated by Party B. So from Corda’s backend process, Party A will issue 100 licenses initially which owner is PartyA, and this shared fact will be initialized as a transaction and will be added to both party’s ledger. Then periodically license usage data will be extracted from Party A’s system and updated the ledger by initializing a transaction, we will use “Move” flow to transfer the license state’s amount and owner. For example, if Party B activated 40 licenses, then Party A’s license state amount will become to 60, and there is another new state which owner is Party B and amount is 40. I thought I should use ownable state for this use case after reading some Corda documentation about linear state and ownable state, but not sure whether my understanding is correct
What is the best practice from Corda about how to design a dynamical contract terms which can be used in smart contract(verify menthod conditions). For example, in the initial version of license management process, two types of licenses and their price will be defined as contract terms, and we plan to define them as the state’s properties(meta data). If later there are one new type need to be added, how should we best handle this situation. Is there any dynamical approach to define the state’s properties/meta data? Our ideal approach is initially there is no any terms defined(no license type pre-defined), and allow user to add different type of license with their price information dynamically on UI, then these dynamically defined contract terms will be stored in CorDapp and can be used in later phase, and this approach can be easily to be “copied” to different providers. Is this possible to do?
Very interesting use case and scenarios. We have not formalized best practices for parent child states in api wrappers, but you can treat the collection of states using the same relational database model as long as your transactions also keep pointers updated.
Our thinking for state representation covers 3 hierarchical scenarios:
1 - portfolio of assets - like an etf or index grouping multiple assets. This can be moved as a new portfolio asset representing a tether to the existing asset data or a grouping function
2 - asset itself - this is a linear state that has a life cycle of events that influence it. Think of this like the company ref data behind the equity
3 - fungible asset representation - cash flow fungible staye that can reference the asset's linear id - think of issued shares for the equity
In this case, the 2 & 3 scenarios have the ref data to fungible state relationship. The fungible state can store the reference to the asset's linear ID and the asset can store an array of owners of the equity. Depending on your queries, you can also store another relational table for mapping different foreign and primary keys. The careful part is taking into account this logic linking when executing transactions that change issuance or ownership
For the standard Ethereum factory pattern, cordapps can be broken up into multiple functions. For example, the obligation cordapp uses the corda-finance-1.0.jar package to share different library functions and definitions on self issuing cash and cash properties.
Coming back to the asset example, we have an interest rate swap example cordapp that has contract code defining the known fields in a standard irs ISDA contract. From this template, you can deploy any irs type of state by defining the field properties like maturity date and interest rate.
I imagine the license use case can create similar fields for types for how the business logic or contract code would see it evolve. This also brings to light a tool gap for wrapping a workflow management tool or interface above the corda fundamentals.
In the Corda-example, if we want to add custom validating code, we can override checkTransaction() in the responder codes to make sure the IOU is above a certain threshold. This assumes that all responders are agreeable to that threshold.
What if we allow every lender to set their own threshold. In that case the threshold becomes a variable. To address this, I created a UI that directly publishes the threshold (an integer) to the database. However I am finding it hard to extract the value and passing it to a threshold variable in the flow code. Is there a better way? If this works, I can quarantine more variables and using the UI for individual nodes, I get to set custom parameters (into the database) used in the validation of the state in the Tx.
The easiest way to achieve this is to provide a different implementation of the flow for each node. For example, if you had an AcceptTxBasedOnThreshold flow, you'd create several implementations:
One AcceptTxBasedOnThreshold flow implementation for NodeA, which perhaps has a threshold of 10
One AcceptTxBasedOnThreshold flow implementation for NodeB, which perhaps has a threshold of 20 instead
And so on for any additional nodes...
You'd then create several CorDapps:
The first CorDapp would include the shared state and contract definitions that everyone uses. You'd install this CorDapp on every node. This CorDapp wouldn't include any flow definitions
You'd then create an additional CorDapp for each node:
A CorDapp with only NodeA's AcceptTxBasedOnThreshold flow. This CorDapp would only be installed by NodeA
A CorDapp with only NodeB's AcceptTxBasedOnThreshold flow. This CorDapp would only be installed by NodeB
1.How should I prevent nodes to have relationships with themselves in neo4j graph?
2.How should I force nodes to have only one relationship with each other,I mean if node A have relationship with node B this way: A--->B, there should not be any B--->A?
I know in graph making everything is on my own so I can handle both of them,but consider there is a java api which user says which nodes and relationships should be created,but I want to prevent user from 1 and 2?
Is there any possibility in neo4j for handling them?
You can implement a [TransactionEventHandler][1] that performs the enforcing your constraints and register it with your GraphDatabaseService instance. A TransactionEventHandler can inspect the contents of the current transaction and eventually veto on committing, see http://docs.neo4j.org/chunked/stable/transactions-events.html.