I am stuck with a problem where I need to implement royalties in my ERC721 collection contract
Usual way is to deploy the contract and set/split royalties on opensea/rarible or other secondary marketplaces.
But if unknown marketplace lists my contract and we dont have royalties implemented there the issue may rise. I read about erc-2981 standard.. Although it’s not implemented by opensea or rarible but it is authentic
But the client requirement is that we need to split the royalties among 2 addresses… Whereas the interface erc-2981 allows only one recipient of the royalty
So I am stuck here about how to implement generic royalties directly on my smart contracts
Related
I am trying to implement an Validator class in Contract-States library of CordApp, which have several validation methods that are inherited by Model classes in their init() fun, so that each time a Model class is called/initialized the validation happens on the spot.
Now I'm stuck at a point, where I need to validate whether the incoming member name(through a Model class) matches with Organisation name of the node, I need to access the NetworkMap for that. How can I do that?
In Work-Flow library each flow extends FlowLogic class that implements ServiceHub interface and through that we can access the NetworkMap, but how to do that in Contract-States library?
P.S. - I'm trying to avoid any circular dependency (Contract-States lib should not depend on Work-Flow lib)
The short answer, you can't.
The long answer:
The difference between flow validations and contract validation is that the latter (contracts) must be deterministic meaning for the same input they must always give the same output whether it's now or after 100 years, in the current node or any other node.
The reason for that is because any time (even in the future) when a node receives a transaction it must validate that transaction which includes validating the inputs which in return requires validating the transaction that created those inputs and so on, until you get a fully validated graph of all the inputs that lead to the outputs that were used as inputs and so on.
That's why the contract should return the same result any time, and that's why it should be deterministic, and that's why contracts (unlike flows) don't have access to external resources (like HTTP calls, or even the node's database).
Imagine if the contract was relying on the node's database for some validation rule, as you know, states are distributed on a need to know basis (i.e. only to participants of the state); so one node might have the state that you're using as validation source and another node won't, so the contract's output (transaction valid/invalid) will differ between nodes, and that breaks the deterministic concept.
Contracts only have access to the transaction components: inputs, outputs, attachments, signatures, time-windows, reference states.
Good news, there are other ways to implement your requirement:
Using an attachment that has the list of nodes that are allowed to be part of the transaction, this method should be used if the blacklist is not updated frequently and you can see the example here.
Using reference states, where you can create a state that has the allowed parties and require the existence of that reference state in your transaction; this method should be used when the blacklist is more frequently updated. You can read about reference states here.
Using Oracles, this option is in case there is a world organization (or for instance Ministry of Trade of some country) that provides an Oracle which returns the list of blacklisted parties; and you use that Oracle in your transaction. You can read about Oracles here.
I'm currently tying to make a CordApp That will be used for DVP, but I'm having trouble understanding some key concepts. For instance, I understand that Contracts apply to one type of state in particular. What I don't really get is if the contract validation logic should apply to only that state object or all the states that will be in the given transaction.
The typical example would be the issuance of a sell order :
The input of a transaction the state of the stock account of the issuer and the outputs are the sell Order and the modified stock account.
Basically my question is were do I do checks like : I don't sell more than I own, the sum of the number of stocks in the sell order and what is left in the account is equal to what was initially in the account, ... ?
I have followed the Corda tutorials but I'm still not clear on that logic.
It boils down to the Orchestration Layer (flows or APIs, what the user intends to do) vs the Ledger layer (what the user can do. IE - guaranteed shared logic).
Contract code absolutely must be adhered to, so in your case not being able to sell more than you own would be part of the explicit contract.
The CMN guide here helped me conceptualise.
Flows are better described as business logic, so anything can be achieved within a flow as long as it adheres to the contract.
A security consideration: Anybody may create a flow, and they are equally able to use any Asset (and thus it's state) within their third-party flow.
It is the relevant contract that ensures that your asset is used for the purpose you imagine, and that it isn't used malevolently.
In Corda, an OwnableState must specify an AbstractParty as an owner. There are two types of AbstractParty:
Party, with a well-known identity
AnonymousParty, identified solely by public key
If I create a CompositeKey to own the OwnableState, who then will store it in their vault as part of FinalityFlow?
At the moment nobody will unless lower level APIs are used.
The vault needs more work to fully understand multi-sig states, e.g. with cash, we need a way to select coins that we're participants of.
It's quite an advanced feature because composite keys have so many use cases. This is typical in the blockchain space, Bitcoin supported CHECKMULTISIG outputs in the protocol long before wallets that knew how to use them existed. And when wallets did start to appear, they had different code and features for different use cases. E.g. using multisig/composite keys for more secure wallets is different to using them to do dispute mediation protocols.
At least with flows we have a straightforward way to implement support - we can make flows that understand composite keys and either have the certs linking the components to real parties, or know who they are some other way, and then go gather the signatures automatically.
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.
I am working on an Adobe Flex front-end with a Java back-end using JPA for persistence. The protocol I am using is remote objects (AMF) implemented with BlazeDS.
I started out with a service-facade and entity DAOs, but without any specific DTOs. The same POJOs, the domain objects, were passed in the service-facade as those used as DTOs passed to the Hibernate DAOs.
However, the latest few days I have been thinking whether this is a good approach or not. The latest article on the subject I read was this one:
Interesting JPA Pattern blog
The situation:
Say I have POJO Book with a unidirection ManyToOne relation with the POJO Category (i.e. each book may only be associated with one category, but the same category may be associated with many books). I see some alternatives:
Alternative 1:
I expose a method/operation addUpdateBook(Book book). In the implementation of this operation I add/update both the book and the referenced category. I mean, if the client submits a book having a category that doesn't exist from before, this would mean that the client implicitly may edit categories using the addUpdateBook operation.
the client is working directly with the domain model!
the entire category information will be sent when a new book is added
even though a reference to the category would be sufficient
Alternative 2:
I expose a method/operation addUpdateBook(Book book,Long categoryId). In the implementation I retrieve the category for the given categoryId and replace the category given in the book POJO and then I persist the book. In other words, I ignore any category in the book object, I just look at the categoryId. This means that the client would need to use another operation in order to modify the category.
pro: the client can still work more or less on the domain model, but ...
con: ... it is confusing for the client that the category of the book
object will be ignored
con: the entire category information of the book will be sent, even
if the server never will read it
pro: it may be more clear when a separate operation should be used
for category modifications
con: I need to retrieve the category before persisting the book. I
guess this means some overhead.
Alternative 3:
I expose a method/operation addUpdateBook(BookDTO bookDto). The POJO BookDTO looks as the POJO Book, but instead of a field Category category it has a field Long categoryId. In the implementation I retrieve the Category for the given categoryId before I persist the Book.
pro: not confusing for the client
con(?): what should the method getBook(Long bookId) return? should it
return only the BookDTO? Then it would be required to invoke also the
operation getCategory(Long categoryId) in order to have "the entire
book information". Then the client would need to set together the
different parts to a local domain representation of the book.
Compared to alternative 1 this would be more complex on the client
side?
con: I need to retrieve the category before persisting the book. I
guess this means some overhead.
con: being forced to use the DTOs in the client makes it deal with physical details thereby and makes it somewhat distant from the actual domain model. It seems like I am missing the point with having an domain model and using JPA in the business layer.
I guess (!) alternative 3 is the way you would design the operations in a SOA context. However, for me, it is not that important to be loosely-coupled between the client and server. My focus is not to provide multiple client-platform support.
Which alternative would you propose? Are there other better alternatives? Do you know any nice resources, such as code examples, which could help me?
I'm using something related to "Alternative 3". In the beginning I've started to use domain objects (probably also because of my experience with dataservices), after a while I found too many problems and I've switched to DTO's. All the publing services are exposing only DTO's (both for input/output parameters).
Some of the problems that I've met during working directly with the domain objects and BlazeDS:
a)you need to break the domain objects encapsulation (like exposing properties, or exposing private constructors) in order to use them for data transfer. Otherwise you will have to write your own serialization/deserialization.
b)you need to use tricks in order to allow data conversion between client/server. For example, using strings instead of dates in order to prevent timezone difference. Or using strings instead of int/double. You can solve some of these issues by writing custom proxies, but I still think that it's easier to use strings instead of other data types.
c)most of the time you don't need all the data from the domain objects, and in order to deal with that you need to use various frameworks with support for data pagination/lazy instantiation on the client. This frameworks are introducing complexity, and I try to stay away from that.
The main disadvantage of using DTO is the amount of boiler code in order to do the conversion between the domain objects-DTOs...but I still prefer using them.