Introduzione a blockchain e registri digitali

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
Getting started with distributed
ledgers and blockchain in the
Cloud

How do we think about blockchain?

Need for a ledger with centralized trust
DMV
Track vehicle
title history
Manufacturers
Track distribution of a
recalled product
HR & Payroll
Track changes to an
individual’s profile
Healthcare
Verify and track hospital
equipment inventory
LEDGERS WITH
CENTRALIZED TRUST
1

Need for running transactions with decentralized trust
2
Financial
institutions
Peer-to-peer payments
Mortgage
lenders
Process syndicated
loans
Supply Chain
Transact with suppliers
and distributers
Retail
Streamline customer
rewards
TRANSACTIONS WITH
DECENTRALIZED TRUST

Blockchain in supply chain
• Each organization has a
trusted copy of the
supply chain data
• Payments can be
automated through
smart contracts
• Identity of components
are immutably tracked
as they move through
the supply chain
• Quality of products can
be monitored and
immediately acted on

Blockchain services at AWS
Amazon Quantum Ledger
Database (QLDB)
Amazon Managed
Blockchain

S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
NEW
Amazon Quantum
Ledger Database (QLDB)
Fully managed ledger database with a
central trusted authority

A history of record keeping
Ancient
Mesopotamia
—
Cuneiform writing—3500 BC
Double-entry
accounting
—
First conceived—1494 AD
Ancient
Egypt
—
Earliest papyrus writing—2500 BC

Challenges customers face
Building Ledgers with traditional databases
Difficult to
manage and scale
Impossible
to verify
Error prone and
incomplete
Resource
intensive
Blockchain approaches
Designed for a
different purpose
Adds unnecessary
complexity

Amazon Quantum Ledger Database (QLDB) (Preview)
Fully managed ledger database
Track and verify history of all changes made to your application’s data
Maintains a sequenced
record of all changes to your
data, which cannot be
deleted or modified; you
have the ability to query and
analyze the full history
Immutable
Uses cryptography to
generate a secure output file
of your data’s history
Cryptographically
verifiable
Easy to use, letting you
use familiar database
capabilities like SQL APIs for
querying the data
Easy to useHighly scalable
Executes 2–3X as
many transactions as
ledgers in common
blockchain frameworks

How Amazon QLDB works

SHA256 Hash
{
name: "John",
surname: "Smith",
address: {
street: "Governor Sq.",
number: "2345",
city: "Gotham"
}
H(T1)=2526f16306c819d651af075934170d2430d246d9ab98d975d28a83baded47ca7
(64 characters hex)
SHA-256
It's one way
It's deterministic
Fast computation
"Avalanche effect"
Withstand collisions

Verifiability in Amazon QLDB
J
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Owner: Traci Russell
Metadata: {
Date:07/16/2012
}
H (T1)
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
H(T1)=2526f16306c819d651af075934170d2430d246d9ab98d975d28a83baded47ca7SHA-256

J
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
H (T1)H (T1) UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
5b1283c2aea4bfa78e5965e6fcfad3be9f977d46f8ce3c83896ce7549be13264H(T2) = 86a90e4166453d9423b84d47dcbd97c0e3099b1a1f0d7cfca6c191d8fd8994ffH(T1) +

H(T2)=86a90e4166453d9423b84d47dcbd97c0e3099b1a1f0d7cfca6c191d8fd8994ff
J
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
DELETE cars
ID:1
Metadata: {
Date: 09/02/2016
}
H(T3)

J
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
DELETE cars
ID:1
Metadata: {
Date: 09/02/2016
}
H(T3)
H(T3)=ae2d64e562ec754ec3194c744eec72c9fdafffc6b559e0414d0e75bf96ca92ad

What is immutability?
1 Tracy buys a car on Aug 3, 2013
2 Tracy sells car to Ronnie
on Sept 10, 2014
DMV QLDB database will add Ronnie’s record
Journal Current stateDMV scenario
3 Ronnie’s car gets in an
accident and gets totaled
DMV QLDB Database adds new row, called “delete”
DELETE
DATE: 09/02/2016
ID Manufacturer Model Year VIN Owner
1 Tesla Model S 2012 123456789 Traci Russell
1 Tesla Model S 2012 123456789 Ronnie Nash
Built from ground-up in such a way that Journal cannot be modified or altered
Entire change history is easily accessible
DMV QLDB database will add Traci’s record

What is verifiability?
Uses cryptography to create a digest of changehistory, acts as aproof
You canuse the digest to prove integrity of any transaction
Cryptographic
technique
Digest
Customer, Ronnie can
verify the date Traci
sold the car to him
was indeed 7/16

Why do immutability and verifiability
matter for customers?
Reduce risk: ensure safeguarding of critical system-of-record applications where a data
loss could potentially cost millions in lost dollars.
Improve data tracking: helps you or any parties that have access to the system to
quickly and accurately track data’s entire lineage, improving efficiency in tracking the
source of issues (e.g., manufacturing defects, maintain supply network data hygiene)
Auditability: helps reduce downtime caused due to audit and compliance issues, saving
hundreds of productivity hours for your team
Reduce implementation effort: building immutability and verifiability in a traditional
way is time consuming, complex, and expensive

Common customer use cases
Manufacturing
Recording components used
in manufacturing
HR & payroll
Tracking changes to an
individual’s profile
Government
Tracking vehicle
title history
Transport & logistics
Tracking transportation
of goods
E-Commerce
Where’s my stuff?
Banking & finance
Keeping track of transactions,
trades and accounts

NEW
Amazon
Managed Blockchain
Fully managed blockchain service, supporting both
Hyperledger Fabric and Ethereum frameworks

Why do customers care about
implementing a blockchain?
Many existing business networks rely on central authorities, which can be inefficient,
expensive, and require time-consuming auditing
A consortium could achieve better outcomes by sharing information, but cannot agree
on how data can be securely and fairly shared
Multiple organizations need to independently verify transaction history and need a
single, up to date, accurate view of data
Business logic among multiple organizations could be simplified through automation
Asset transfers require an expensive and inefficient escrow

Customers are experimenting in many industries
Proof of Ownership
Digital Security Trading
Documents/Contracts
Enterprise Platforms
Financial
Insurance
Mortgage Loans
Voting Mechanisms
Patient Records
Corporate Governance
HCLS
Real Estate
Legal
Agriculture
Gaming
M & E
Transportation
Digital Advertising
Power/Utilities
Retail
Capital Markets
Cloud
OWNERSHIPPRIVATE MARKETS
DERIVATIVES
WAGERS
GLOBAL PAYMENTS
REMITTANCE
NOTARISATION
EQUITY
MICROFINANCE
INTELLECTUAL PROPERTY
TITLE RECORD
ESCROW
DIGITAL RIGHTS
E-COMMERCE
DEBT
CROWDFUNDING
P2P LENDING
HEALTHCARE
VOTING
TRUSTEES
SMART
CONTRACTS
DIGITAL
CURRENCY
SECURITIES
RECORD
KEEPING
BLOCKCHAIN
TECHNOLOGY

Blockchain builds trust in a network
Eliminates the need for central authority in business networks
Three main components: distributed ledger, consensus mechanism,
and “smart contract” execution environment
Together these elements allow two parties to transact with one another by ensuring other parties consent
to the transaction and record the transaction. This provides immutability and trust

Blockchain components: Distributed Ledger database
The journal records an immutable log of all transactions
and is maintained by nodes in the blockchain network
Block 61
Block hash:
000044bf2efe32
Previous block hash:
000087ea2ffe94
Timestamp
Transaction
Transaction
Block 61
Block hash:
000087ea2ffe94
000057ec2fda71
Timestamp
Transaction
Transaction
Block 61
Block hash:
000057ec2fda71
0000d68b2f0a3b
Timestamp
Transaction
Transaction

Blockchain components: Consensus mechanism
Some important attributes
• Byzantine fault tolerance
• Transaction rate, energy consumption
• Hardware requirements
• Security

Blockchain components: “smart contracts”
• Rules embedded in app
• Verified execution of code
• Conditional operators
• Application writes to ledger
• Contract can interact with
components outside of the
blockchain network (off-chain)

Public and permissioned networks
Public networks allow anyone to
participate in the network. Members are
incentivized to maintain the network
Permissioned networks limit
the members to known entities

Hyperledger Fabric and Ethereum benefits
Useful for a finite set of known users
Well-suited for applications that require stringent
privacy and permission controls with a known set
of members
For example, a financial application where certain
trade-related data is only shared with select banks
and other members in the network don’t have
access to the data
Hyperledger Fabric
Useful for an infinite number of unknown users
Well suited for highly distributed blockchain
networks where transparency of data for all
members is important
For example, a digital identity network comprising
of farmers and government organization, where an
infinite number of farmers can join the network and
information regarding their land, crop yields, etc., is
shared across all members on the blockchain
Ethereum

Challenges with existing blockchain solutions
Complicated
to manage
Setup is hard Hard to scale Expensive

Amazon Managed Blockchain
Easily create and manage scalable blockchain networks
Quickly create blockchain
networks that span multiple
AWS accounts. Easily add or
remove members and monitor
the network
Fully managed Choice of Hyperledger
Fabric or Ethereum
Improves reliabilityScalable and secure
Easily scale your blockchain
network as the usage grows.
Also, Managed Blockchain
secures your network
certificates with KMS
Choose the right framework for
your needs, whether you are
building a permissioned or
public network
Managed Blockchain improves
the reliability of the “ordering
service,” by replacing the
default technology with QLDB.
This improves durability

How Amazon Managed Blockchain works
Amazon Managed
Blockchain
Create a network
Choose an open source
blockchain framework, set
up a new blockchain network
and your membership in
your AWS account with
just a few clicks
Invite members
Invite other AWS accounts to
join the network
Add nodes
Create and configure
blockchain peer nodes that
store a copy of the
distributed ledger
Deploy applications
Create and deploy
decentralized applications
to your network through
your per nodes. Transact
with other members on
the network

Network 1 – Managed Blockchain
VPC endpoint
VPC endpoint
Account A
Account B

Transaction flow with Hyperledger Fabric
Verify policy
Peer-1
Peer-n
Transaction simulation
Ordering service
Submitting-client
2
5
6 Transaction delivery to peers
Transaction proposal1
Endorsement signature3
Broadcast endorsement4

Augmented Hyperledger Fabric
Ordering service
• Core component of a Fabric network to guarantee delivery and
order of transactions
• Production grade networks using open source will utilize Apache
Kafka for this component
• Managed Blockchain uses Amazon QLDB technology, increasing
durability and reliability
Certificate authority
• Open source uses a “soft” HSM
• Managed Blockchain uses AWS Key Management Service (AMS KMS)
to secure the Certificate Authority service

Chaincode basics
Code executed on the network, and can query and update ledger
Fabric supports chaincode in three languages:
Chaincode execute within a docker container on peer nodes
Chaincode has two operations in its interface:
• Init()—initializes the chaincode with parameters
• Invoke()—invokes the chaincode with parameters

Peer nodes
Ordering service
blob3
blckNo
tx1
tx2
Block
forming
blob1
Verify endorsement, readset
If OK then apply writeset
Else invalid transaction (blob)
Genesis block
Submitting
client
Peer
Validated Ledger (VL)PeerLedger
PeerLedger Validated Ledger
blockblock seqNo=blckNo
3
4
seqNo
blob1
blob2
Orders
• Stores a copy of
the ledger database
• Executes chaincode and
endorses transactions
• Validates transactions
before the final commit
to ledger

Channels for access control
Channels allow isolation of
transactions among specific
members in the network
Create or update a
channel with configuration
transaction (configtx)
Member 1 Member 2 Member 3
Channel 2
Ledger
Channel 1
Ledger
Hyperledger Fabric ordering service
Channel 2Channel 1
Member 2
Peer
Member 3
Peer
Member 1
Peer

Endorsement policies
Endorsement policies allow
chaincode to specify which
members (or how many)
need to validate a transaction
before submitting
Endorsed transactions
then get submitted to
the ordering service and
assembled into blocks
Member 1
client
Hyperledger Fabric ordering service
Ledger LedgerMember 2
Peer
Member 1
Peer
1
3 2
1
3

Who ”owns” the network?
• Networks are decentralized and can remain active even after the
initial creator leaves
• Inviting members to join
• Preview: network creator can invite
• GA: members vote on who to invite and remove
• Network-wide settings
• GA: members can vote on network-wide settings and configure the
actual voting rules (e.g., majority rules or one member decides)
• Each member pays for their resources
• Amazon Managed Blockchain manages shared components like the
ordering service and networking settings

• Pay-as-you-go with no upfront costs
• Hourly rates billed per-second
• Each member pays for their own
resources and the data it writes to
the network
• VPC endpoints created to
access resource endpoints are
billed separately
• Standard data transfer rates
Pricing dimensions

Starter edition and standard edition
Starter edition
• Test and small production networks
• Up to 5 members/network
• Up to 2 peer nodes/member
• bc.t3.small and bc.t3.medium
• 1 TiB maximum/peer node
• Ordering service provisioned has lower
transaction throughput and availability
than that in a Standard Edition network
Membership pricing rate is different for each edition
Standard edition
• Production networks
• Up to 30 members/network
• Up to 10 peer nodes/member
• bc.t3, bc.m5, and bc.c5 instance families
• 15 TiB maximum/peer node
• Ordering service provisioned has higher
transaction throughput and availability
than that in a Starter Edition network

Summary: helping customers identify the right
AWS blockchain service
Owned by a single, trusted authority
Addresses core need of a immutable and
verifiable transactional log
It’s a database, so its fast, as it doesn’t
require consent from members
Amazon QLDB Amazon Managed Blockchain
No single owner of the ledger. Joint
ownership by multiple parties
Addresses core need of enabling multiple parties to transact
transparently and with trust with each other
Removes intermediaries when a group of members needs to
transact. So it makes business processes more efficient
Ownership
Addresses Need
Key Benefit

Databases
Our portfolio
Broad and deep portfolio, purpose-built for builders
Redshift
Data warehousing
EMR
Hadoop + Spark
Athena
Interactive analytics
Kinesis Data Analytics
Real time
Elasticsearch Service
Operational Analytics
RDS
MySQL, PostgreSQL, MariaDB,
Oracle, SQL Server
Aurora
MySQL, PostgreSQL
QuickSight SageMaker
DynamoDB
Key value, Document
ElastiCache
Redis, Memcached
Neptune
Graph
Timestream
Time Series
QLDB
Ledger Database
S3/Glacier
Glue
ETL & Data Catalog
Lake Formation
Data Lakes
Database Migration Service | Snowball | Snowmobile | Kinesis Data Firehose | Kinesis Data Streams
Data movement
Analytics
Business intelligence & machine learning
Data lake
Managed
Blockchain
Blockchain
Templates
Blockchain
RDS on VMware
NEW
NEW
NEW
NEW
NEW

Next steps
Learn more about our services and sign up for our preview today!
Amazon Managed Blockchain landing page: https://aws.amazon.com/managed-blockchain
Deep dive on Amazon Managed Blockchain: https://www.youtube.com/watch?v=B9tlH8lzKI4
How to deploy an app with AMB: https://aws.amazon.com/blogs/database/tag/amazon-managed-blockchain/
Deep dive on Amazon QLDB: https://www.youtube.com/watch?v=7G9epn3BfqE&t
Amazon QLDB landing page: https://aws.amazon.com/qldb
What is Ledger Database? https://www.youtube.com/watch?v=BiEbMJ86dGQ&t

Thank you!
Gianluca Nieri

Blockchain in financial services

NEW

AWS database categories and use cases
Relational Key-value Document In-memory Graph Time-series Ledger
Referential integrity,
ACID transactions,
schema-on-write
High throughput,
low-latency reads
and writes,
endless scale
Store documents and
quickly access
querying on any
attribute
Query by key with
microsecond latency
Quickly and easily
create and navigate
relationships
between data
Collect, store, and
process data
sequenced by time
Complete,
immutable, and
verifiable history of
all changes to
application data
Lift and shift, ERP,
CRM, finance
Real-time bidding,
shopping cart, social,
product catalog,
customer preferences
Content
management,
personalization,
mobile
Leaderboards,
real-time analytics,
caching
Fraud detection,
social networking,
recommendation
engine
IoT applications,
event tracking
Systems
of record, supply
chain, health care,
registrations,
financial

How to get started on AWS
AWS partners offer
a wide range of
blockchain
frameworks,
services, and
solutions

How it works

How it works
ID Version Start Manufacturer Model Year VIN Owner
J
history.cars
H
current.cars
C

How it works
J
history.cars
H
current.cars
C
INSERT INTO cars <<
{ 'Manufacturer':'Tesla',
'Model':'Model S',
'Year':'2012',
'VIN':'123456789',
'Owner':'Traci Russell' }
>>

How it works
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
INSERT INTO cars <<
'Model':'Model S',
'Year':'2012',
'VIN':'123456789',
>>

How it works
1 1 07/16/2012 Tesla Model S 2012 123456789 Traci Russell
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
INSERT INTO cars <<
'Model':'Model S',
'Year':'2012',
'VIN':'123456789',
>>

How it works
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}

How it works
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
UPDATE cars SET owner = 'Ronnie Nash' WHERE VIN = '123456789'

How it works
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
H (T2)

How it works
1 2 08/03/2013 Tesla Model S 2012 123456789 Ronnie Nash
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
H (T2)

How it works
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
H (T2)

How it works
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
H (T2)
DELETE FROM cars WHERE VIN = '123456789'

How it works
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
H (T2) DELETE cars
ID:1
Metadata: {
Date: 09/02/2016
}
H (T3)

How it works
1 3 09/02/2016 Deleted
J
history.cars
H
current.cars
C
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
H (T2) DELETE cars
ID:1
Metadata: {
Date: 09/02/2016
}
H (T3)

Traditional database

How it works
history.cars
H
current.cars
C

How it works
history.cars
H
current.cars
C
INSERT INTO cars <<
'Model':'Model S',
'Year':'2012',
'VIN':'123456789',
>>

How it works
history.cars
H
current.cars
C
INSERT INTO cars <<
'Model':'Model S',
'Year':'2012',
'VIN':'123456789',
>>
Stored procedure

How it works
history.cars
H
current.cars
C
Stored procedure

How it works
1 3 09/02/2016 Null Null Null Null Null
history.cars
H
current.cars
C
Stored procedure

How it works
1 3 09/02/2016 Null Null Null Null Null
history.cars
H
current.cars
C
Stored procedure
2012-07-16:
New entry: { 'Manufacturer':'Tesla',
'Model':'Model S',
'Year':'2012', …
2013-08-03:
Owner updated to Ronnie Nash
2016-09-02:
Removed from system

More on digests
J
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
DELETE cars
ID:1
Metadata: {
Date: 09/02/2016
}
H(T3)

More on digests
J
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
ID:1
Owner: Ronnie Nash
Metadata: {
Date:08/03/2013
}
DELETE cars
ID:1
Metadata: {
Date: 09/02/2016
}
H(T3)
H(T1)=25d0b44e6e8878151646ffc1fea4eb85c3e4bf4baec212a9fcf67b6d5a81e01a
H(T2)=a90a9898c7e4b1aab19c705b554afd9e0bf6539bb0346df19be362ff63001098
H(T3)=c6268578a24dbe0c7cfba07bd967411a35462b8c875d42f1991faad02c0ac93c

Computing SHA-256
https://doi.org/10.6028/NIST.FIPS.180-4

Computing SHA-256
O=> sha256sum
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
2526f16306c819d651af075934170d2430d246d9ab98d975d28a83baded47ca7 -

Computing SHA-256
https://www.movable-type.co.uk/scripts/sha256.html
Cryptographic Hash Algorithm © 2005-2017 Chris Veness
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Metadata: {
Date:07/16/2012
}
2526f16306c819d651af075934170d2430d246d9ab98d975d28a83baded47ca7

Computing SHA-256
“Mining Bitcoin with
pencil and paper”
Ken Shirriff
http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html

Relational data model
Customers
ID Name Email Address ID Phone
Orders
ID Customer ID Date Total Shipping
Address ID
Status
Order Items
ID Order ID Item Quantity Price
Addresses
ID Street City State ZIP

Modern programming languages
order = {
'Id': "694262fb-9d43-4f94-8c3b-12ae66ce74f9”,
'Customer': <Customer object at 0x0x7f7e057243a8>,
'Date': 2018-11-23 11:25:36.00,
'Total': 137.53,
'ShippingAddr': {
'Street': "100 Elm St",
'City': "Seattle",
'State': "WA",
'Zip': "98101",
},
'Status': "Processing",
'Items': [ {
'SKU': “70ffb504-af12-4612-8b74-0dac4f8fd534”,
'Quantity': 2,
'Price': 15.21
}
. . .

Document data model
Order {
Id: UUID
CustomerId: UUID
Date: DateTime
Total: Integer
ShippingAddr: Address
Status: String
Items: [ OrderItem ]
}
Address {
Street: String
City: String
State: String
Zip: String
}
OrderItem {
SKU: UUID
Quantity: Integer
Price: Decimal
}

Querying Amazon QLDB
SELECT *
FROM orders AS o, addresses AS a
WHERE a.state = ‘WA’
AND o.shipping_address_id = a.id
Find all orders that are being shipped to Washington
SELECT *
SELECT *
FROM orders AS o,
WHERE o.shipping_address.state = ‘WA’
SELECT *
FROM orders AS o
WHERE o.shipping_address.state = ‘WA’
SELECT *
Traditional SQL
QLDBSELECT *
FROM orders AS o,

Querying Amazon QLDB
SELECT *
Find all orders (with items) for a given customer
SELECT *
FROM orders AS o, o.items AS oi
WHERE o.customer_id = 648bf6b0-caab-4967-9a09-36ecd2798470
AND o.id = oi.order_id
SELECT *
FROM orders AS o
SELECT *
FROM orders AS o, order_items AS oi
Traditional SQL
QLDBSELECT *
FROM orders AS o, order_items AS oi
SELECT *
FROM orders AS o, o.items AS oi

Sign up for our preview today!
https://aws.amazon.com/qldb

Thank you!

Introduzione a blockchain e registri digitali

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Introduzione a blockchain e registri digitali

Similar to Introduzione a blockchain e registri digitali (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Introduzione a blockchain e registri digitali