on 24-Sep-2018 (Mon)

Corda is a decentralised database platform with the following novel features:
• New transaction types can be defined using JVM 4 bytecode.
• Transactions may execute in parallel, on different nodes, without either node being aware of the other’s transactions

The data model allows for arbitrary object graphs to be stored in the ledger. These graphs are called states and are the atomic unit of data.
• Nodes are backed by a relational database and data placed in the ledger can be queried using SQL as well as joined with private tables, thanks to slots in the state definitions that are reserved for join keys.
• The platform provides a rich type system for the representation of things like dates, currencies, legal entities and financial entities such as cash, issuance, deals and so on.
• States can declare a relational mapping and can be queried using SQL.
• Integration with existing systems is considered from the start. The net- work can support rapid bulk data imports from other database systems without placing load on the network. Events on the ledger are exposed via an embedded JMS compatible message broker.
• States can declare scheduled events. For example a bond state may declare an automatic transition to an “in default” state if it is not repaid in time.

range(5) returns[0, 1,2,3,4]

range(5,9) returns (5, 6, 7, 8]

range(3, 10, 3) returns [3, 6, 9]

对于灾害，按重要程度准备应该是先准备水和食物，然后才是电源、手电、工具什么的。水一般家里常备一些瓶装水，日常喝也就更新了，另外要准备单兵净水吸管和净水药片，在瓶装水喝完后，可以喝被污染的水。食物，MRE那种单兵自热食品，按人数备一个星期的，快过期时去露营一两次吃掉，更新。还有压缩饼干。手电，最好是用CR123或AA这种电池的头灯，防止可充锂电的手电没及时充电。和外面联系，准备UV双段的手台，换高增益天线，或准备其他形式方便架设的高增益天线，注意维护电池，能用AA电池的更好，民用频率对讲机用处不大。自救必备的常用小工具，折叠钳，求生刀一类的。12V电池，电瓶、锂电什么的都行，还是注意维护充电。12V车充，用电池给手机充电用，接头也要准备好。2盒避孕套，别买容易破的。上面是一些基本的，最好装在防水防压的箱子里，放在方便拿的位置。下面推荐的，有条件最好也准备，减少自身危险和提高生活质量用的。有条件多备食物，压缩饼干首选，单兵自热其次。药品，抗生素、退烧药、止痛药、感冒药，这是一类的，外伤用药和纱布胶带，是另一类，还有根据预计的避难人情况准备针对个人的药，比如治哮喘、降压等药，这三类药是基本配置。锅、户外炉具、燃料，一般用高山气炉就行了，避免在避难时只能吃冷食物生病，城市里很难找到木头一类的燃料。防火毯、防毒面具，用于建筑物内起火时逃生。短波电台和方便架设的天线，及电台的电池，电池注意维护充电，在整个地区通信中断时，与外界联系用。不推荐使用收音机，如果不是全国性的大灾难，不会在收音机电台里说什么的。营地灯等照明设备，有条件可以准备一台发电机，平时油桶加满油。所有的东西放在固定且不易被损坏的地方，要考虑建筑物倒塌后能不能拿到的问题，要考虑防水和抗压，还要方便平时维护电池，所以放在哪得动动脑筋。

We' ll also look at ~ac~9 ~ a feature provided by Abaqus, that makes it easy to create simple scripts without requiring any actual coding.

The work directory is C:\Temp by default, a nd you can chan · g~ j{ using Fil~ ; - S~fWork . Dire~tory.. · - ~ The easiest way to look up the necessary commands is to perform an action in Abaqus/CAE and then open up this replay file. If it is currently in use Abaqus may not let you open it;. in this case right click on it and choose copy to create a copy of it in Windows Explorer that you can open.

You notice that the name of our macro ' BiockMacro' is the name of the function (indicated by the def keyword).

Corda reuses the standard PKIX infrastructure for connecting public keys to identities and thus names are actually X.500 names. When a single string is sufficient the common name field can be used alone, similar to the web PKI. In more complex deployments the additional structure X.500 provides may be useful to differentiate between entities with the same name. For example there are at least five different companies called American Bank and in the past there may have been more than 40 independent banks with that name.

3.3 The network map Every network requires a network map service, which may itself be composed of multiple cooperating nodes. This is similar to Tor’s concept of directory authorities. The network map publishes the IP addresses through which every node on the network can be reached, along with the identity certificates of those nodes and the services they provide. On receiving a connection, nodes check that the connecting node is in the network map. The network map abstracts the underlying IP addresses of the nodes from more useful business concepts like identities and services. Each participant on the network, called a party, publishes one or more IP addresses in the network map. Equivalent domain names may be helpful for debugging but are not required. User interfaces and APIs always work in terms of identities – there is thus no equivalent to Bitcoin’s notion of an address (hashed public key), and user-facing applications rely on auto-completion and search rather than QRcodes to identify a logical recipient. It is possible to subscribe to network map changes and registering with the map is the first thing a node does at startup. Nodes may optionally advertise their nearest city for load balancing and network visualisation purposes. The map is a document that may be cached and distributed throughout the network. The map is therefore not required to be highly available: if the map service becomes unreachable new nodes may not join the network and existing nodes may not change their advertised service set, but otherwise things continue as normal

The reference implementation provides this functionality using the Apache Artemis message broker, through which it obtains journalling, load balancing, flow con- trol, high availability clustering, streaming of messages too large to fit in RAM and many other useful features. The network uses the AMQP/1.0 7 protocol which is a widely implemented binary messaging standard, combined with TLS to secure messages in transit and authenticate the endpoints

Messages may also have an associated organising 64-bit session ID. Note that this is distinct from the AMQP notion of a session. Sessions can be long lived and persist across node restarts and network outages. They exist in order to group messages that are part of a flow, described in more detail below.

Messages that are successfully processed by a node generate a signed acknowl- edgement message called a ‘receipt’. Note that this is distinct from the unsigned acknowledgements that live at the AMQP level and which simply flag that a message was successfully downloaded over the wire. A receipt may be generated some time after the message is processed in the case where acknowledgements are being batched to amortise signing overhead, and the receipt identifies the message by the hash of its content. The purpose of the receipts is to give a node undeniable evidence that a counterparty received a notification that would stand up later in a dispute mediation process. Corda does not attempt to support de- niable messaging

In Corda transaction data is not globally broadcast. Instead it is transmitted to the relevant parties only when they need to see it. Moreover even quite simple use cases – like sending cash – may involve a multi-step negotiation between counterparties and the involvement of a third party such as a notary. Additional information that isn’t put into the ledger is considered essential, as opposed to nice-to-have. Thus unlike traditional block chain systems in which the primary form of communication is global broadcast, in Corda all communication takes the form of small multi-party sub-protocols called flows

The flow framework presents a programming model that looks to the developer as if they have the ability to run millions of long lived threads which can survive node restarts, and even node upgrades. APIs are provided to send and receive object graphs to and from other identities on the network, embed sub-flows, and report progress to observers. In this way business logic can be expressed at a very high level, with the details of making it reliable and efficient abstracted away. This is achieved with the following components.

Just-in-time state machine compiler. Code that is written in a blocking manner typically cannot be stopped and transparently restarted later. The first time a flow’s call method is invoked a bytecode-to-bytecode transformation occurs that rewrites the classes into a form that implements a resumable state machine. These state machines are sometimes called fibers or coroutines, and the transformation engine Corda uses (Quasar) is capable of rewriting code arbitrarily deep in the stack on the fly. The developer may thus break his or her logic into multiple methods and classes, use loops, and generally structure their program as if it were executing in a single blocking thread. There’s only a small list of things they should not do: sleeping, directly accessing the network APIs, or doing other tasks that might block outside of the framework

Transparent checkpointing. When a flow wishes to wait for a message from another party (or input from a human being) the underlying stack frames are suspended onto the heap, then crawled and serialized into the node’s underlying relational database using an object serialization framework. The written objects are prefixed with small schema definitions that allow some measure of portability across changes to the layout of objects, although portability across changes to the stack layout is left for future work. Flows are resumed and suspended on demand, meaning it is feasible to have far more flows active at once than would fit in memory. The checkpointing process is atomic with changes to local storage and acknowledgement of network messages.

Identity to IP address mapping. Flows are written in terms of identities. The framework takes care of routing messages to the right IP address for a given identity, following movements that may take place whilst the flow is active and handling load balancing for multi-homed parties as appropriate

A library of subflows. Flows can invoke sub-flows, and a library of flows is provided to automate common tasks like notarising a transaction or atomically swapping ownership of two assets

Progress reporting. Flows can provide a progress tracker that indicates which step they are up to. Steps can have human-meaningful labels, along with other tagged data like a progress bar. Progress trackers are hierarchical and steps can have sub-trackers for invoked sub-flows

Flow hospital. Flows can pause if they throw exceptions or explicitly request human assistance. A flow that has stopped appears in the flow hospital where the node’s administrator may decide to kill the flow or provide it with a solution. The ability to request manual solutions is useful for cases where the other side isn’t sure why you are contacting them, for example, the specified reason for sending a payment is not recognised, or when the asset used for a payment is not considered acceptable

When a transaction is presented to a node as part of a flow it may need to be checked. Simply sending you a message saying that I am paying you £1000 is only useful if you are sure I own the money I’m using to pay you. Checking transaction validity is the responsibility of the ResolveTransactions flow. This flow performs a breadth-first search over the transaction graph, downloading any missing transactions into local storage and validating them. The search bottoms out at the issuance transactions. A transaction is not considered valid if any of its transitive dependencies are invalid. It is required that a node be able to present the entire dependency graph for a transaction it is asking another node to accep

Small-subgraph transactions. Some uses of the ledger do not involve widely circulated asset states. For example, two institutions that wish to keep their view of a particular deal synchronised but who are making related payments off-ledger may use transactions that never go outside the involved parties. A discussion of on-ledger vs off-ledger cash can be found in a later section

Transaction privacy techniques. Corda supports a variety of transaction data hiding techniques.

State re-issuance. In cases where a state represents an asset that is backed by a particular issuer, and the issuer is trusted to behave atomically even when the ledger isn’t forcing atomicity, the state can simply be ‘exited’ from the ledger and then re-issued. Because there are no links between the exit and reissue transactions this shortens the chain. In practice most issuers of highly liquid assets are already trusted with far more sensitive tasks than reliably issuing pairs of signed data structures, so this approach is unlikely to be an issue.

Transactions consist of the following components:

• Input references These are (hash, output index) pairs that point to the states a transaction is consuming.
• Output states Each state specifies the notary for the new state, the contract(s) that define its allowed transition functions and finally the data itself.
• Attachments Transactions specify an ordered list of zip file hashes. Each zip file may contain code, data, certificates or supporting docu- mentation for the transaction. Contract code has access to the contents of the attachments when checking the transaction for validity.
• Commands There may be multiple allowed output states from any given in- put state. For instance an asset can be moved to a new owner on the ledger, or issued, or exited from the ledger if the asset has been redeemed by the owner and no longer needs to be tracked. A command is essentially a parameter to the contract that specifies more information than is obtainable from exam-ination of the states by themselves (e.g. data from an oracle service). Each command has an associated list of public keys. Like states, commands are object graphs.
• Signatures The set of equired signatures is equal to the union of the com- mands’ public keys.
• ​​​​​​​Type Transactions can either be normal or notary-changing. The validation rules for each are different.
• Timestamp When present, a timestamp defines a time range in which the transaction is considered to have ccurrred. This is discussed in more detail below.
• Summaries Textual summaries of what the transaction does, checked by the involved smart contracts. This field is useful for secure signing devices

Composite keys are useful in multiple scenarios. For example, assets can be placed under the control of a 2-of-2 composite key where one leaf key is owned by a user, and the other by an independent risk analysis system. The risk analysis system refuses to sign if the transaction seems suspicious, like if too much value has been transferred in too short a time window. Another example involves encoding corporate structures into the key, allowing a CFO to sign a large transaction alone but his subordinates are required to work together. Composite keys are also useful for notaries. Each participant in a distributed notary is represented by a leaf, and the threshold is set such that some participants can be offline or refusing to sign yet the signature of the group is still valid.

Transaction timestamps specify a [start, end] time window within which the transaction is asserted to have occurred. Timestamps are expressed as windows because in a distributed system there is no true time, only a large number of desynchronised clocks. This is not only implied by the laws of physics but also by the nature of shared transactions - especially if the signing of a transac- tion requires multiple human authorisations, the process of constructing a joint transaction could take hours or even days.

Timestamps are checked and enforced by notary services. As the participants in a notary service will themselves not have precisely aligned clocks, whether a transaction is considered valid or not at the moment it is submitted to a notary may be unpredictable if submission occurs right on a boundary of the given window. However, from the perspective of all other observers the notary’s signature is decisive: if the signature is present, the transaction is assumed to have occurred within that time.

Transactions may have a number of attachments, identified by the hash of the file. Attachments are stored and transmitted separately to transaction data and are fetched by the standard resolution flow only when the attachment has not previously been seen before

Attachments provide data but do not authenticate it, so if there’s a risk of someone providing bad data to gain an economic advantage

a state can not only name a class that implements the Contract interface but also place constraints on the zip/jar file that provides it. That constraint can in turn be used to ensure that the contract checks the authenticity of the data – either by checking the hash of the data directly, or by requiring the data to be signed by some trusted third party

As Corda contracts are simply zip files, it is easy to include a PDF or other documents describing what a contract is meant to actually do. There is no requirement to use this mechanism, and there is no requirement that these doc- uments have any legal weight. However in financial use cases it’s expected that they would be legal contracts that take precedence over the software implemen- tations in case of disagreement

There is no direct equivalent in Corda of a block chain “hard fork”, so the only solution to discarding buggy or fraudulent transaction chains would be to mutually agree out of band to discard an entire transaction subgraph. As there is no global visibility either this mutual agreement would not need to encompass all network participants: only those who may have received and processed such transactions.

Determining the set of entities that’d have to agree to discard a subgraph means correlating node activity logs. Corda nodes log sufficient information to ensure this correlation can take place. The platform defines a flow to assist with this, which can be used by anyone. A tool is provided that generates an “investigation request” and sends it to a seed node. The flow signals to the node administrator that a decision is required, and sufficient information is transmitted to the node to try and convince the administrator to take part (e.g. a signed court order).

Once involved parties are identified there are at least two strategies for editing the ledger. One is to extend the transaction chain with new transactions that simply correct the database to match the intended reality. For this to be possible the smart contract must have been written to allow arbitrary changes outside its normal business logic when a sufficient threshold of signatures is present. This strategy is simple and makes the most sense when the number of parties involved in a state is small and parties have no incentive to leave bad information in the ledger. For asset states that are the result of theft or fraud the only party involved in a state may resist attempts to patch things up in this way, as they may be able to benefit in the real world from the time lag between the ledger becoming inaccurate and it catching up with reality. In this case a more complex approach can be used in which the involved parties minus the uncooperative party agree to mark the relevant states as no longer consumed/spent. This is essentially a limited form of database rollback.