Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


https://www.hyperledger.org/wp-content/uploads/2019/11/HL_SolutionsBrief_ReduceCost_V8.pdf



View file
nameHyperledger Inter-Carrier Settlement WPv1.0.pdf
height250

White Paper Checklist

  •  Send group whitepaper template to use as a starting point
  •  Review and copy edit before publishing
  •  Post on Publications page
  •  Plan social media posts
  •  Create home page banner
  •  Invite Chair to TSC call to discuss (if paper is technical)
  •  Announce whitepaper (and TSC discussion if one is happening) on MC call

...

Last Name

First Name

Company

Company URL

Contact Email

Zelawat

Sunay

Subex Ltd.

www.subex.com

sunay.zelawat@subex.com

Gunasekaran

Shyam Prabhu

Subex Ltd.

www.subex.com

shyam.prabhu@subex.com

Zanotto

Paulo

Subex Ltd.

www.subex.com

paulo.zanotto@subex.com

Saleh

Bilal

Pacioli Consulting

https://pacioli.us

bilal@pacioli.us

Rathi

Vipin

DU


vipin68_scs@jnu.ac.in

Thomas

Mathews

IBM

www.ibm.com

matthom@us.ibm.com

Singh

Amandeep

IBM

www.ibm.com

singham@us.ibm.com

Muscara

Barbara

Ledger Academy

www.ledgeracademy.com

Bobbi@LedgerAcademy.com

NimaAfrazConnect Centrehttps://connectcentre.ienafraz@tcd.ie
ChaudharyVinayNIC
vcteotia@gmail.com


Whitepaper:

Hyperledger [title, as few words as possible]

Purpose of This Paper

The purpose of this white paper is to define how a blockchain-based solution can help telecommunication service providers settle cross-charging payments efficiently and quickly by reducing friction and removing intermediaries.  The final deliverable is a Proof of Concept (PoC) that demonstrates the functionality of the Minimum Viable Product (MVP).

[If something is NOT covered that a reader might reasonably expect to find here, say so. From then on, use the construction... “Any further discussion of (said topic) is beyond the scope of this document.”]

Intended Audience

The primary audience of this white paper are network operators who are interested in reducing the cost of cross-charging settlements, as well as technical people who are interested developing the PoC.

Introduction3

1.1 subsection--topic 13

...

[list all the contributors to the white paper in alphabetical order by LAST name. Many working groups keep a list of members or contributors on their wiki pages or their minutes. Don’t include anyone’s name without their okay.]







  1.  Introduction


This white paper will describe the inefficiencies and problems of the current system telecommunication network operators use to settle charges amongst themselves.  The paper will also propose a solution based and a PoC based on Hyperledger to make the system more efficient and cost effective.  

1.1 subsection--topic 1

[If needed, break up the Introduction in subsections. Always have at least 2 subsections, 1.1 and 1.2 or else this numbering system looks unnecessary.]

1.2 subsection--topic 2

[same as above]

1.3 subsection--topic 3

[same as above, if needed]

[Add a page break at the end of the Introduction]






  1. Title for topic 1

[Start this section with a brief paragraph that describes what’s in this section. This helps readers know if they need to read this or they can skip it to go onto another topic they’re more interested in.]

...

[By default, list items in alphabetical order. if you prefer to use some order, state it: in order of size, in order by first on the market, and so on.]

2.1 subsection--topic 1

[If needed, break this section up in subsections. Always have at least 2 subsections, 2.1 and 2.2 or else this numbering system looks unnecessary.]

2.2 subsection--topic 2

[same as above]

2.3 subsection--topic 3

[same as above, if needed]

[Add a page break at the end of this section]







  1. Title for topic 2

[Start this section with a brief paragraph that describes what’s in this section. This helps readers know if they need to read this or they can skip it to go onto another topic they’re more interested in.]

...

[Add a page break at the end of this section]


  1. Title for topic 3

[Start this section with a brief paragraph that describes what’s in this section. This helps readers know if they need to read this or they can skip it to go onto another topic they’re more interested in.]

4.1 subsection--topic 1

[If needed, break this section up into subsections. Always have at least 2 subsections, 4.1 and 4.2 or else this numbering system looks unnecessary.]

4.2 subsection--topic 2

[same as above]

4.3 subsection--topic 3

[same as above, if needed]

[Add a page break at the end of this section]


  1. Title for topic 4

[Start this section with a brief paragraph that describes what’s in this section. This helps readers know if they need to read this or they can skip it to go onto another topic they’re more interested in.]

5.1 subsection--topic 1

[To include a table, create the table right in the GDoc. You can use the table below as a starting point. Give it a number (Table 1, Table 2, etc.) and a short, clear title and then reference it in the text:

...

[When the white paper is prepared for publication, the designer will recreate the table to look nicer and use the Linux Foundation publication template.]

Table 1: Summary of Hyperledger Frameworks


FRAMEWORK

BRIEF DESCRIPTION

SEE ALSO

HYPERLEDGER FABRIC

A platform for building distributed ledger solutions with a modular architecture that delivers a high degree ofconfidentiality, flexibility, resiliency, and scalability. This enables solutions developed with Hyperledger Fabric to be adapted for any industry.

6.2

HYPERLEDGER SAWTOOTH

A modular platform for building, deploying, and running distributed ledgers. Sawtooth features a new type of consensus, proof of elapsed time (PoET) which consumes far fewer resources than proof of work (PoW).

6.3


5.2 subsection--topic 2

[same as above]

5.3 subsection--topic 3

[same as above, if needed]

[Add a page break at the end of this section]


  1. Conclusions

This white paper explained... [sum up the white paper briefly. This section “tells them what you told them.” Although this may seem repetitive, some people flip to the back of a document to see “the bottom line” and what they might have missed.]

...

[In this section, list any further resources or interesting reading that might illuminate the topic more. Include enough detail so that a reader could easily locate that source, including URLs if appropriate.]

Notes


[Although GDocs can’t do Endnotes, the designer will move all your footnotes here. In every footnote, provide the AUTHOR(s), the article or document TITLE, the PUBLISHER, the DATE, and if you have it, the PAGE NUMBER. For a website, include the URL and RETRIEVED ON DATE.]

...