# Observation of anisotropic Dirac cones in the topological material Ti2Te2P

Gyanendra Dhakal  Department of Physics, University of Central Florida,
Orlando, Florida 32816, USA  Firoza Kabir  Department of Physics, University
of Central Florida, Orlando, Florida 32816, USA  Ashis K. Nandy  Department of
Physics and Astronomy, Uppsala University, P. O. Box 516, S-75120 Uppsala,
Sweden  School of Physical Sciences, National Institute of Science Education
and Research, An OCC of Homi Bhabha National Institute, Jatni-752050, India
Alex Aperis  Department of Physics and Astronomy, Uppsala University, P. O.
Box 516, S-75120 Uppsala, Sweden  Anup Pradhan Sakhya  Department of Physics,
University of Central Florida, Orlando, Florida 32816, USA  Subhadip Pradhan
School of Physical Sciences, National Institute of Science Education and
Research, An OCC of Homi Bhabha National Institute, Jatni-752050, India
Klauss Dimitri  Department of Physics, University of Central Florida, Orlando,
Florida 32816, USA  Christopher Sims  Department of Physics, University of
Central Florida, Orlando, Florida 32816, USA  Sabin Regmi  Department of
Physics, University of Central Florida, Orlando, Florida 32816, USA  M.
Mofazzel Hosen  Department of Physics, University of Central Florida, Orlando,
Florida 32816, USA  Yangyang Liu  Department of Physics, University of Central
Florida, Orlando, Florida 32816, USA  Luis Persaud  Department of Physics,
University of Central Florida, Orlando, Florida 32816, USA  Dariusz
Kaczorowski  Institute of Low Temperature and Structure Research, Polish
Academy of Sciences, Okolna 2, 5–420 Wroclaw, Poland  Peter M. Oppeneer
Department of Physics and Astronomy, Uppsala University, P. O. Box 516,
S-75120 Uppsala, Sweden  Madhab Neupane∗ Department of Physics, University of
Central Florida, Orlando, Florida 32816, USA

(27 October, 2017)

###### Abstract

Anisotropic bulk Dirac (or Weyl) cones in three dimensional systems have
recently gained intense research interest as they are examples of materials
with tilted Dirac (or Weyl) cones indicating the violation of Lorentz
invariance. In contrast, the studies on anisotropic surface Dirac cones in
topological materials which contribute to anisotropic carrier mobility have
been limited. By employing angle-resolved photoemission spectroscopy and
first-principles calculations, we reveal the anisotropic surface Dirac
dispersion in a tetradymite material Ti2Te2P on the (001) plane of the
Brillioun zone. We observe the quasi-elliptical Fermi pockets at the
$\bar{M}$-point of the Brillouin zone forming the anisotropic surface Dirac
cones. Our calculations of the $\mathbb{Z}_{2}$ indices confirm that the
system is topologically non-trivial with multiple topological phases in the
same material. In addition, the observed nodal-line like feature formed by
bulk bands makes this system topologically rich.

The experimental discovery of a three-dimensional (3D) topological insulator
(TI) in tetradymite Bi2Se3 brought about an unprecedented surge of research
interests in exotic states of matter [1, 2, 3, 5, 6, 7, 8, 4]. This discovery
motivated investigations of other novel phases such as the Dirac semimetal,
Weyl semimetal, nodalline semimetal, topological crystalline insulator, Kondo
insulator, etc [9, 10, 11, 12, 13, 14, 15, 16, 17, 18]. Not only have the
discoveries of these novel states provided new classifications of materials,
but a series of compounds with similar electronic behaviors have also been
identified. Recently, a great deal of interest has been directed at a series
of bismuth- and antimony-based tetradymite crystals as they host a topological
surface state while simultaneously possessing a wide bulk band gap, as such a
single 2D Dirac cone in the Brillouin zone (BZ) is present [6, 7, 21, 23, 22,
24, 25, 26, 19, 20, 27]. Similarly, angle-resolved photoemission spectroscopy
(ARPES) studies of the 221-type compounds isostructural to the tetradymite
family such as Zr2Te2P, and Hf2Te2P [28, 29, 30] reveal the presence of
topological surface states along with multiple fermionic-states in the BZ. In
Zr2Te2P, multiple Dirac cones are reported, among which two Dirac cones reside
within the pseudo gap. Additionally, it contains a surface state anisotropic
Dirac cone at the $\bar{M}$ point [28]. Another compound of this family,
Hf2Te2P, possesses multiple topological states, hosting strong TI and weak TI
states in a single material. Furthermore, it consists of a one-dimensional
Dirac-node arc along a high symmetry direction which makes this family even
more fascinating [30]. Interestingly, the band inversion takes place between
the d and p bands in these compounds in contrast to other tetradymite families
which host band inversion between s and p bands or between p bands [27, 28,
29, 30, 31].
Most of the well studied TIs and topological semimetals (TSMs) have isotropic
Dirac cones which are dubbed as type-I fermions. Bi2Se3, Cd3As2 and TaAs are
prime examples of materials hosting type-I fermions in TI, Dirac and Weyl
semimetallic states, respectively [6, 10, 13]. However, very recently
topological states with tilted Dirac cones have gained significant attention.
Subsequently, type-II Weyl semimetal [32] and type-II Dirac semimetals [33,
34, 35] have been discovered in three dimensional systems. These anisotropic
Dirac cones are formed by bulk bands. Type-II fermions have tilted Dirac cones
as a result of broken Lorentz invariance, and Dirac or Weyl nodes exist at the
contact of electron and hole energy pockets [32]. In a similar fashion,
anisotropic Dirac cones have been reported in two dimensional systems in which
Fermi velocities vary along high symmetry directions [36, 37, 38]. The
anisotropy of the Dirac cone might provide anisotropic carrier mobility, thus
leading to the realization of direction-dependent transport for quantum
devices [36, 38]. A few materials harboring anisotropic surface Dirac cones
have been reported [39, 40, 41, 28, 42, 43]. However, the examples of 2D
anisotropic Dirac cones are limited in 3D materials.

Figure 1: Crystal structure and band structure calculations of Ti2Te2P: (a)
Crystal structure of Ti2Te2P stacked in hexagonal layers, in which blue, brown
and pink balls identify Te, Ti and P atoms, respectively. The dotted-
rectangles enclose quintuple layers. (b) 3D bulk Brillouin zone (BZ) of single
crystals and its projected hexagonal surface where the high-symmetry points
are labeled. (c) First-principles calculation of the bulk bands with inclusion
of the spin-orbit coupling.

In this work, we investigate the electronic band structures of the (001)
surface of Ti2Te2P using high-resolution vacuum ultraviolet ARPES and first-
principles calculations. Our measurements reveal the presence of anisotropic
surface Dirac cones at the $\bar{M}$ point and nodal-line-like features along
the $\bar{\Gamma}$-$\bar{M}$ direction. The experimental results are in
excellent agreement with the first-principles calculations. Parity
calculations reveal the band-inversions at the $\Gamma$ and the F point
indicating that the system is topologically rich. The anisotropic Dirac cones
have the potential to be used in technological applications due to the
different mobilities in a Dirac cone.

Figure 2:  Fermi surface map and electronic band dispersions of Ti2Te2P: (a)
Fermi surface map and constant energy contours at different binding energies
measured at a photon energy of 100 eV. The white colored hexagonal shape is a
constructed BZ in order to identify the high symmetry points. Band dispersion
along the (b) $\bar{K}$-$\bar{\Gamma}$-$\bar{K}$, (c)
$\bar{M}$-$\bar{\Gamma}$-$\bar{M}$ and (d) $\bar{K}$-$\bar{M}$-$\bar{K}$
directions. (e) Calculated band dispersion map along the
$\bar{K}$-$\bar{M}$-$\bar{K}$ direction. In the energy axis, the Dirac point
is set as zero. All the measured data were collected in ALS beamline 4.0.3 at
a temperature of 16 K.

Single crystals of Ti2Te2P were grown by chemical vapor transport method as
described in Ref. [1, 2], and details of sample characterizations are
described in the Supplemental Material (SM) note 1 [46].

Synchrotron-based ARPES measurements were performed at the Advanced Light
Source (ALS) beamline 10.0.1 equipped with Scienta R4000, ALS beamline 4.0.3
equipped with R8000 hemispherical electron analyzers, and at the SIS-HRPES
end-station at the Swiss Light Source (SLS) equipped with Scienta R4000.
Similarly, helium lamp based ARPES measurements were performed at the
Laboratory for Advanced Spectroscopic Characterization of Quantum Materials
(LASCQM) with R3000 hemispherical analyzer at University of Central Florida.
The angular and energy resolutions were set to be better than 0.2∘ and 20 meV,
respectively. The electronic structure calculations and structural
optimization were carried out within the density-functional formalism, which
are described in SM Note 2 [46, 3, 4, 5, 6, 7].

Figure 3: Experimental observation of anisotropic Dirac cone: (a) Fermi
surface map in which white-colored lines are drawn via the $\bar{M}$ point to
show angles of dispersion maps with respect to the
$\bar{K}$-$\bar{M}$-$\bar{K}$ direction. (b) Dispersion maps along different
orientions, angles with respect to $\bar{K}$-$\bar{M}$-$\bar{K}$ direction are
noted on the top of plots. All data were collected at the beamline 4.0.3 in
ALS at a photon energy of 100 eV.

We begin our discussion by presenting the crystal structure of Ti2Te2P in Fig.
1(a ). It is isostructural to the Bi2Te2Se, which crystallizes in a
rhombohedral crystal structure with lattice parameter a = 3.6387(2) Å, c =
28.486(2) Å and space group $R\bar{3}m$ (No. 166), each unit cell consisting
of three quintuple atomic layers separated by van der Waals gaps [1]. The
phosphorus and tellurium atoms are arranged in hexagonal layers stacked along
the hexagonal c-axis in a sequence with two layers of tellurium followed by a
single layer of phosphorus and the gap is filled by titanium as shown in Fig.
1(a). The (001) plane is the natural cleaving plane in this compound due to
the atomic layers along the c-axis. A three dimensional BZ and its projection
to 2D along the [001] direction are presented in Fig. 1(b), which illustrates
the hexagonal symmetry of the (001) surface BZ. Figure 1(c) shows the bulk
band calculation of Ti2Te2P (with spin-orbit coupling (SOC)) along the high
symmetry directions which includes four time reversal invariant momenta (TRIM)
points. It shows a hole-like band around the $\Gamma$ point. A band is seen
crossing the chemical potential at the $\Gamma$ point indicating the
semimetallic behavior, which is flat in the vicinity of the Fermi level at the
$\Gamma$ point. Our detailed electronic structures calculations show the
occurrence of bulk band inversion both at the $\Gamma$ and the F point. These
band inversions are between Ti-p and Te-d states and involve different sets of
bands (see SM [46]). A bulk band inversion at the $F$ point takes place
between Ti p and Te d bands around 750 meV below the Fermi level, which agrees
well with both the calculated and observed Dirac surface state at the
$\bar{M}$ point. This surface state is of the strong TI type, since our
calculated $Z_{2}$ indices for this case are (1;000) (see SM [46]). Unlike the
other sister compounds of this family (Zr2Te2P, Hf2Te2P), Ti2Te2P does not
possess band inversion above the chemical potential at the zone center. The
parity analysis of this system shows that a strong TI state exist at the
$\Gamma$ point and at the $M$ point (see SM for the parity calculation [46]).
Our calculations indicate that the band inversion between different bulk bands
at the $\Gamma$ point also leads to strong TI topology with $\mathbb{Z}_{2}$
again (1;000). Remarkably, this band inversion takes place near a similar
binding energy as the one responsible for the Dirac surface state at the
$\bar{M}$ point (see [46]).
Figure 2 illustrates the detailed electronic structures of experimentally
measured Ti2Te2P by using synchrotron based high resolution ARPES. In Fig.
2(a), the Fermi surface map is presented which has a six-fold flower petal
shape as a consequence of the presence of the three-fold rotational and
inversion symmetry. At the $\bar{\Gamma}$ point, a circular-shaped energy
pocket can be seen due to the hole-like band that crosses the chemical
potential. Furthermore, a constructed BZ is presented in which high-symmetry
points are labeled. The photoemission spectra obtained from ARPES measurements
suggests that petal shaped Fermi pockets are surface originated as they do not
disperse significantly with photon energies (see SM [46]). The impacts of the
matrix elements effects are noticeable leading to non-uniform spectral
intensities. Furthermore, petal-like features coming from the secondary BZ can
be observed at the edges. The ARPES measured Fermi surface of Ti2Te2P is
similar to Fermi-surface of the Zr2Te2P and Hf2Te2P [28, 29, 30]. The energy
contours delineate how the band dispersions evolve with the binding energies.
The energy pockets at the $\bar{\Gamma}$ point grow bigger with binding energy
indicating the hole nature of the bands at the $\bar{\Gamma}$ point. This
hexagonal BZ has six $\bar{M}$-points at the center of the elliptical Fermi
pockets. The diameters of the elliptical petal diminish with binding energies.
At the binding energy of 750 meV, the elliptical features collapse into lines.
Furthermore, the line-like feature seen along the $\bar{\Gamma}$-$\bar{M}$
direction form nodal-line-like states as it is the crossing point of bulk
Dirac dispersions (see SM [46]). Interestingly, there are an even number of
topological nontrivial surface states at the $\bar{\Gamma}$ point and one at
the $\bar{M}$ point, which provide the condition for Dirac-node arcs [30].
However, we do not observe gapped bulk Dirac cones in the vicinity of the
$\bar{\Gamma}$ as seen in Hf2Te2P, probably due to weaker spin-orbit coupling,
or due to energy resolution limitations obscuring the gap in the photoemission
intensity plot. The node arc feature is protected by in-plane time-reversal
invariance similar to its sister compound Hf2Te2P. In order to study the
dispersion maps along high symmetry axes, we present ARPES measurements of
energy dispersion along high symmetry directions. Figure 2(b) shows band
structures along the $\bar{K}$-$\bar{\Gamma}$-$\bar{K}$ direction. Hole-like
bands are seen in the vicinity of the Fermi level. Another band exists almost
750 meV below the Fermi level, which can be seen in the bulk band
calculations. Figure 2(c) displays the dispersion map along the
$\bar{M}$-$\bar{\Gamma}$-$\bar{M}$, in which hole-like bands can be seen. The
slab calculations (see SM [46]) suggest that most of the bands are bulk
originated, whereas a pair of surface originated bands are buried within bulk
bands.
In Fig. 2(d), we present the dispersion map along the
$\bar{K}$-$\bar{M}$-$\bar{K}$ direction in which, we observe a Dirac state at
the binding energy of 750 meV. Our photon energy dependent measurements
suggest the surface-originated Dirac cone, however the slab calculations (see
Fig. 2(e)) suggests the presence of bulk bands. The bulk bands and surface
bands, however, cannot be resolved in the present resolution.
To show the anisotropic Dirac cones at the $\bar{M}$ points, we have taken
dispersion maps along the different directions at the $\bar{M}$ point which
have different Fermi velocities. Figure 3(a) shows the Fermi surface map in
which one $\bar{M}$ point is chosen as a reference point to demonstrate the
anisotropy of the Dirac state at the $\bar{M}$ point. The Dirac cones are
formed by the elliptical shaped petals at the Fermi surface. In Fig. 3(b),
dispersion maps along the different directions are presented, which make
angles of 0∘-80∘ at an interval of 20∘. The dispersion maps delineate the
presence of anisotropic Dirac cones.

Figure 4: Demonstration of anisotropy in a Dirac cone: (a) Experimental
momentum distribution curves (MDCs) [red open circles] integrated within 4 meV
of the corresponding binding energy and fitted (black solid lines) to the
experimental MDCs along cut 1 as shown in (c). (b) Same as (a) but along cut 4
i.e, rotated by 60∘ with respect to the $\bar{K}$-$\bar{M}$-$\bar{K}$
direction. (c) Zoomed in view of the Fermi surface where the yellow lines 1-6
indicates cut directions in the interval of 20∘. (d) The k|| dispersions as a
function of binding energy. The co-ordinates are obtained from the MDCs plots
from (a) and (b). (e) The k|| values as a function of rotation angles with
respect to the $\bar{K}$-$\bar{M}$-$\bar{K}$ direction.

To quantitatively determine the anisotropy of the Dirac cone in Ti2Te2P, we
have performed a detailed analysis along both cut 1 i.e, along the
$\bar{K}$-$\bar{M}$-$\bar{K}$ high-symmetry direction and cut 6 which is
rotated 60∘ with respect to the $\bar{K}$-$\bar{M}$-$\bar{K}$ direction [see
Figs. 4(a)-4(c)]. Figures 4(a)-4(b) show the momentum distribution curves
(MDCs)(red open circles) which are extracted from the ARPES dispersions. In
order to fit the obtained MDCs, Gaussian-Lorentzian (GL) product functions
have been used. The Gaussian part represents primarily the energy resolution
of the instrument and the lifetime broadening of the photoelectrons, whereas
the core holes are captured by the Lorentzian width [52, 53]. The fitted MDCs
as shown in Figs. 4a-b show accurate fits upto around 750 meV i.e, near the
Dirac point. From the obtained results one can see that along cut 1, the
dispersion of the topological surface states (TSSs) follows a linear behavior
whereas along cut 4 the dispersion of the TSS deviated quite strongly from the
linear behavior (see Fig. 4(d)). The different behavior of the dispersion of
the TSS along the different directions thus clearly shows the anisotropic
dispersion of the TSS. The magnitude of the Fermi velocity associated with cut
1 is almost double of cut 4. Fig. 4(e) displays the change in the k|| vector
as a function of the rotation angle where the rotation has been performed with
respect to the high symmetry direction $\bar{K}$-$\bar{M}$-$\bar{K}$; it
clearly shows a significant increase of the k|| wave vector above 40∘
rotation.
The anisotropic surface Dirac cone in a 3D system has been overlooked despite
substantial works done on the tilted bulk Dirac cones in semimetallic systems.
The anisotropic Dirac cone at the $\bar{M}$ point of Ti2Te2P is the
consequence of the petal shaped energy pocket at the $\bar{M}$ point in the
BZ, due to which the Fermi velocities vary along the directions of the
dispersion maps. The anisotropy of TSSs in some materials have been observed
[54, 7, 55, 56, 43, 41], which are attributed to the spin-dependent scattering
giving rise to anisotropic scattering rates of the surface-state electrons,
however the role of spin-dependent scattering in Ti2Te2P is yet to be
revealed. Importantly, materials with anisotropic surface Dirac cones could be
a platform that provide a direction dependent transport. It requires further
explorations in such materials.
In conclusion, we observe anisotropic Dirac cones at the $\bar{M}$ points in
Ti2Te2P material. Our $\mathbb{Z}_{2}$ calculations identify this system as
topologically non-trivial. The presence of nodalline like features along the
$\bar{\Gamma}$-$\bar{M}$ direction in addition to the anisotropic Dirac cones
makes this system topologically rich. Our study provides an archetype system
for the understanding of the 221-tetradymite system and we anticipate that it
will stimulate further research interests in this class of materials.

M.N. acknowledges support from the Air Force Office of Scientific Research
under Award No. FA9550-17-1-0415, the Air Force Office of Scientific Research
MURI (Grant No. FA9550-20-1-0322), and the National Science Foundation (NSF)
CAREER award DMR-1847962. A.K.N., A.A., and P.M.O. acknowledge support from
the Swedish Research Council (VR) and from the Knut and Alice Wallenberg
Foundation (Grant No. 2015.0060). Computational resources were provided by the
Swedish National Infrastructure for computing (SNIC)(Grant No. 2018-05973). A.
K. N. acknowledges the support of Department of Atomic Energy (DAE) and
Science and Engineering Research Board (SERB) research grant (Grant No.
SRG/2019/000867) of the Government of India. We thank Sung-Kwan Mo and
Jonathan Denlinger for beamline assistance at the LBNL. This research used
resources of the Advanced Light Source, a U.S. DOE Office of Science User
Facility under contract no. DE-AC02-05CH11231. We thank Nicholas Clark Plumb
for beamline assistance at the SLS, PSI.
∗ Corresponding author<EMAIL_ADDRESS>
## References

  * [1] M. Z. Hasan and C. L. Kane, Rev. Mod. Phys. 82, 3045 (2010).
  * [2] X.-L. Qi and S.-C. Zhang, Rev. Mod. Phys. 83, 1057(2011).
  * [3] M. Z. Hasan, S.-Y. Xu, and M. Neupane, Topological Insulators, Topological Dirac semimetals, Topological Crystalline Insulators, and Topological Kondo Insulators. in Topological Insulators: Fundamentals and Perspectives eds Ortmann F., Roche S., Valenzuela S. O. John Wiley & Sons (2015).
  * [4] A. Bansil, H. Lin, T. Das, Rev. Mod. Phys. 88, 021004-021037 (2016).
  * [5] L. Fu, C. L. Kane, E. J. Mele, Phys. Rev. Lett. 98, 106803 (2007).
  * [6] Y. Xia, D. Qian, D. Hsieh, L. Wray, A. Pal, H. Lin, A. Bansil, D. Grauer, Y. S. Hor, R. J. Cava, and M. Z. Hasan, Nat. Phys. 5, 398 (2009).
  * [7] Y. L. Chen, J. G. Analytis, J.-H. Chu, Z. K. Liu, S.-K. Mo, X. L. Qi, H. J. Zhang, D. H. Lu, X. Dai, Z. Fang, S. C. Zhang, I. R. Fisher, Z. Hussain, and Z.-X. Shen, Science $\mathbf{325}$, 178 (2009).
  * [8] Y. Ando, and L. Fu, Annu. Rev. Condens. Matter Phys. $\mathbf{6}$, 361 (2015).
  * [9] Z. Wang, H. Weng, Q. Wu, X. Dai, and Z. Fang, Phys. Rev. B 88, 125427 (2013).
  * [10] M. Neupane, S.-Y. Xu, R. Sankar, N. Alidoust, G. Bian, C. Liu, I. Belopolski, T.-R. Chang, H.-T. Jeng, H. Lin, A. Bansil, F. Chou, and M. Z. Hasan, Nat. Commun. $\mathbf{5}$, 3786 (2014).
  * [11] B.-J. Yang and N. Nagaosa, Nat. Commun. 5, 4898 (2014).
  * [12] S. M. Young, S. Zaheer, J. C. Y. Teo, C. L. Kane, E. J. Mele, and A. M. Rappe, Phys. Rev. Lett. 108, 140405 (2012).
  * [13] S.-Y. Xu, I. Belopolski, N. Alidoust, M. Neupane, G. Bian, C. Zhang, R. Sankar, G. Chang, Z. Yuan, C.-C. Lee et al., Science 349, 613 (2015).
  * [14] H. Weng, C. Fang, Z. Fang, B. A. Bernevig, X. Dai, Phys. Rev. X 5, 011029 (2015).
  * [15] M. Neupane, I. Belopolski, M. M. Hosen, D. S. Sanchez, R. Sankar, M. Szlawska, S.-Y. Xu, K. Dimitri, N. Dhakal, P. Maldonado et al., Phys. Rev. B 93, 201104(R) (2016).
  * [16] M. M. Hosen, K. Dimitri, I. Belopolski, P. Maldonado, R. Sankar, N. Dhakal, G. Dhakal, T. Cole, P. M. Oppeneer, D. Kaczorowski et al., Phys. Rev. B 95, 116101(R) (2017).
  * [17] L. Fu, Phys. Rev. Lett. 106, 106802 (2011).
  * [18] M. Neupane, N. Alidoust, S. Y. Xu, T. Kondo, Y. Ishida, D. J. Kim, C. Liu, I. Belopolski, Y. J. Jo, T. R. Chang et al., Nat. Commun. 4, 2991(2013).
  * [19] M. Neupane, S. Basak, N. Alidoust, S. Y. Xu, C. Liu, I. Belopolski, G. Bian, J. Xiong, H. Ji, S. Jia et al., Phys. Rev. B $\mathbf{88}$, 165129 (2013).
  * [20] S.-Y. Xu, M. Neupane, C. Liu, D. Zhang, A. Richardella, L. Andrew Wray, N. Alidoust, M. Leandersson, T. Balasubramanian, J. Sánchez-Barriga et al., Nat. Phys. $\mathbf{8}$, 616 (2012).
  * [21] Z. Ren, A. A. Taskin, S. Sasaki, K. Segawa, and Y. Ando, Phys. Rev. B $\mathbf{82}$, 241306 (R) (2010).
  * [22] H. Ji, J. M. Allred, M. K. Fuccillo, M. E. Charles, M. Neupane, L. A. Wray, M. Z. Hasan, and R. J. Cava, Phys. Rev. B $\mathbf{85}$, 201103(R) (2012).
  * [23] C. Pauly, G. Bihlmayer, M. Liebmann, M. Grob, A. Georgi, D. Subramaniam, M. R. Scholz, J. Sánchez-Barriga, A. Varykhalov, S. Blügel, O. Rader, and M. Morgenstern, Phys. Rev. B 86, 235106 (2012).
  * [24] C.-K. Lee, C.-M. Cheng, S.-C. Weng, W.-C. Chen, K.-D. Tsuei, S.-H. Yu, M. M.-C. Chou, C.-W. Chang, L.-W. Tu, H.-D. Yang, C.-W. Luo, and M. M. Gospodinov, Sci. Rep. 6, 36538 (2016).
  * [25] J. E. Moore, Nature $\mathbf{464}$, 194-198 (2010).
  * [26] M. Neupane, A. Richardella, J. Sánchez-Barriga, S. Xu, N. Alidoust, I. Belopolski, C. Liu, G. Bian, D. Zhang, D. Marchenko et al., Nat. Commun. 5, 3841 (2014).
  * [27] H. J. Zhang, C. X. Liu, X. L. Qi, X. Dai, Z. Fang, and S. C. Zhang, Nat. Phys. 5, 438 (2009).
  * [28] H. Ji, I. Pletikosić, Q. D. Gibson, G. Sahasrabudhe, T. Valla, and R. J. Cava, Phys. Rev. B 93, 045315 (2016).
  * [29] K. W. Chen, N. Aryal, J. Dai, D. Graf, S. Zhang, S. Das, P. Le Fèvre, F. Bertran, R. Yukawa, K. Horiba et al., Phys. Rev. B 97, 165112 (2018).
  * [30] M. M. Hosen, K. Dimitri, A. K. Nandy, A. Aperis, R. Sankar, G. Dhakal, P. Maldonado, F. Kabir, C. Sims, F. Chou et al., Nat. Commun. 9, 3002 (2018).
  * [31] J. Dai, E. Frantzeskakis, N. Aryal, K.-W. Chen, F. Fortuna, J. E. Rault, P. Le Fèvre, L. Balicas, K. Miyamoto, T. Okuda, E. Manousakis, R. E. Baumbach, A. F.Santander-Syro, Phys. Rev. Lett. 126, 196407(2021).
  * [32] A. A. Soluyanov, D. Gresch, Z. Wang, Q. Wu, M. Troyer, X. Dai, and B. A. Bernevig, Nature (London) 527, 495 (2015).
  * [33] H. Huang, S. Zhou, and W. Duan, Phys. Rev. B 94, 121117 (R) (2016).
  * [34] C. Le, S. Qin, X. Wu, X. Dai, P. Fu, Chen Fang, and J. Hu, Phys. Rev. B 96, 115121(2017).
  * [35] T.-R. Chang, S.-Y. Xu, D. S. Sanchez, W.-F. Tsai, S.-M. Huang, G. Chang, C.-H. Hsu, G. Bian, I. Belopolski, Z.-M. Yu et al., Phys. Rev. Lett. 119, 026404(2017).
  * [36] B. Feng, J. Zhang, S. Ito, M. Arita, C. Cheng, L. Chen, K. Wu, F. Komori, O. Sugino, K. Miyamoto et al., Adv. Mater. 30, 1704025 (2018).
  * [37] H.-Y. Lu, A. S. Cuamba, S.-Y. Lin, L. Hao, R. Wang, H. Li, Y. Zhao, and C. S. Ting, Phys. Rev. B 94, 195423 (2016).
  * [38] Y. Zhao, X. Li, J. Liu, C. Zhang, and Q. Wang, J. Phys. Chem. Lett. 9, 1815 (2018).
  * [39] J. Park, G. Lee, F. Wolff-Fabris, Y. Y. Koh, M. J. Eom, Y. K. Kim, M. A. Farhan, Y. J. Jo, C. Kim, J. H. Shim, and J. S. Kim, Phys. Rev. Lett. 107, 126402 (2011).
  * [40] B. Feng, J. Zhang, S. Ito, M. Arita, C. Cheng, L. Chen, K. Wu, F. Komori, O. Sugino, K. Miyamoto et al., Sci. Rep. 4, 5385 (2014).
  * [41] Q. D. Gibson, D. Evtushinsky, A. N. Yaresko, V. B. Zabolotnyy, M. N. Ali, M. K. Fuccillo, J. Van den Brink, B. Büchner, R. J. Cava, and S. V. Borisenko, Sci. Rep. 4, 5168 (2014).
  * [42] F. Virot, R. Hayn, M. Richter, and J. van den Brink, Phys. Rev. Lett. 106, 236806 (2011).
  * [43] W. Zhang, R. Yu, W. Feng, Y. Yao, H. Weng, X. Dai, and Z. Fang, Phys. Rev. Lett. 106, 156808 (2011).
  * [44] F. Philipp, P. Schmidt, M. Ruck, W. Schnelle, and A. Isaeva, J. Solid State Chem. $\mathbf{181}$, 2859 (2008).
  * [45] J. S. Oh, H.-S. Yu, C.-J. Kang, S. Sinn, M. Han, Y. J. Chang, B.-G. Park, K. Lee, B. I. Min, S. W. Kim, H.-D. Kim, and T. W., Chem. Mater. $\mathbf{28}$, 7570 (2016).
  * [46] See Supplemental Materials for photon energy dependent measurements, different direction dispersion maps, constant energy contours etc.
  * [47] G. Kresse and J. Furthmüller, Phys. Rev. B. 54, 11169–11186 (1996).
  * [48] G. Kresse, and J. Furthmüller, Comput. Mater. Sci. 6, 15–50 (1996).
  * [49] J. P. Perdew, K. Burke, and M. Ernzerhof, Phys. Rev. Lett. 77, 3865–3868 (1996).
  * [50] G. Kresse, and D. Joubert, Phys. Rev. B 59, 1758–1775 (1999).
  * [51] P. E. Blöchl, Phys. Rev. B 50, 17953–17979(1994).
  * [52] T. Valla, A. V. Fedorov, P. D. Johnson, B. O. Wells, S. L. Hulbert, Q. Li, G. D. Gu, N. Koshizuka, Science 285, 2110 (1999).
  * [53] T. Valla, Z.-H. Pan, D. Gardner, Y. S. Lee, and S. Chu Phys. Rev. Lett. 108, 117601 (2012).
  * [54] K. Kuroda, M. Arita, K. Miyamoto, M. Ye, J. Jiang, A. Kimura, E. E. Krasovskii, E. V. Chulkov, H. Iwasawa, T. Okuda et al., Phys. Rev. Lett. 105, 076802 (2010).
  * [55] S. Souma, K. Kosaka, T. Sato, M. Komatsu, A. Takayama, T. Takahashi, M. Kriener, K. Segawa, and Y. Ando, Phys. Rev. Lett. 106, 216803 (2011).
  * [56] J. Sánchez-Barriga, M. R. Scholz, E. Golias, E. Rienks, D. Marchenko, A. Varykhalov, L. V. Yashina, and O. Rader, Phys. Rev. B. 90, 195413 (2014).

> Supplementary Materials

Supplementary Note 1: Synthesis and bulk characterization of Ti2Te2P crystals
Single crystals of Ti2Te2P were grown by the standard chemical vapor transport
method. The obtained crystals were thin platelets with typical dimensions 0.5
$\times$ 0.5 $\times$ 0.06 mm3. They had dark metallic luster and were found
moderately stable against air and moisture. Their chemical composition was
checked by energy-dispersive X-ray analysis ( EDAX) using an FEI scanning
electron microscope equipped with an EDAX Genesis XM4 spectrometer. Results
confirmed that the material is homogeneous single-phase with the stoichiometry
close to the nominal one (see Fig. S1). The crystal structure was verified by
single crystal X-ray diffraction performed on a Kuma-Diffraction KM4 four-
circle diffractometer equipped with a CCD camera using Mo K$\alpha$ radiation.
The results confirmed the rhombohedral space group R$\bar{3}$m, and yielded
the lattice parameters similar to those reported in the literature [1, 2].
Electrical resistivity measurements were carried out within the temperature
range of 2-300 K using a conventional four-point ac technique implemented in a
Quantum Design PPMS platform. The electrical contacts to as-grown crystals
were prepared using silver epoxy paste. The electrical resistivity was
measured with electrical current flowing within the hexagonal plane of the
Ti2Te2P crystal lattice.

Figure S2 shows the temperature dependence of the electrical resistivity of
single-crystalline Ti2Te2P, measured within the hexagonal plane of the
crystallographic unit cell. The compound exhibits metallic characteristics in
regards to electrical transport, in concert with the previous report [2].
However, at the lowest temperatures, the resistivity saturates at a constant
value that can be associated with the residual scattering of conduction
electrons on structural imperfections, at odds with the observation in Ref.
[2] of a logarithmic upturn below 7 K that was attributed to weak localization
or electron-electron interaction. Here, it should be noted that the specimen
investigated in Ref. [2] was an ultra-thin flake exfoliated from a bulk
crystal using the scotch type method, while in the present case it was a
parallelepiped cut from a larger single-crystalline piece. The different form
of the samples explains the discrepancy in the magnitude of the resistivity
measured at room temperature (ca. 114 versus 30 $\mu\Omega$-cm, in the present
study and Ref. [2], respectively) and at 2 K (ca. 24.4 versus 3.5
$\mu\Omega$-cm, respectively). Furthermore, it clarifies the absence in the
resistivity data displayed in the inset to Fig. S2 of any clear features due
to quantum corrections.

Supplementary Note 2: First-principles calculations of Ti2Te2P
Structural optimization was carried out within the density-functional
formalism as implemented in the Vienna ab initio simulation package (VASP) [3,
4]. Exchange and correlation were treated within the generalized gradient
approximation (GGA) using the parametrization of Perdew, Burke, and Ernzerhof
(PBE) [5]. The projector augmented wave (PAW) method [6, 7] was employed for
the wave functions and pseudo potentials to describe the interaction between
the ion cores and valence electrons. The lattice constants and atomic
geometries were fully optimized and obtained by minimization of the total
energy of the bulk system. The surface of the 2D crystal was simulated as a
slab calculation within the supercell approach with sufficiently thick vacuum
layers. In addition to the general scalar-relativistic corrections in the
Hamiltonian, the spin-orbit interaction was taken into account. The plane wave
cutoff energy and the k-point sampling in the BZ integration were checked
carefully to assure the numerical convergence of self-consistently determined
quantities.

Supplementary Note 3: Surface and bulk bands in Ti2Te2P
Fermi surface maps at different photon energies confer an opportunity to study
the surface nature of the Fermi pockets. Surface bands do not disperse with
the photon energy. In Fig. S3, it is evident that the petal-like energy
pockets do not change their shape and size with change in photon energies
which indicates that the bands originate from the surface. Figure S4
illustrates the ARPES measured dispersion maps and their corresponding slab
calculations along the high symmetry directions
$\bar{M}$-$\bar{\Gamma}$-$\bar{M}$ (Fig. S4(a)) and
$\bar{K}$-$\bar{M}$-$\bar{K}$ (Fig. S4(b)), respectively. In the vicinity of
the $\bar{\Gamma}$ point as shown in Fig. S4(a), a pair of hole-like surface
bands is present along with bulk bands. One band crosses the Fermi level,
whereas, other bands remain below the Fermi level. Ultimately, they merge at a
certain $k$-point between the $\bar{\Gamma}$ and the $\bar{M}$ point to become
a single band. Unlike other sister compounds of this family, it does not have
a topological insulating state above the Fermi level. As discussed in the main
text, the anisotropic Dirac cone is clearly seen on the theoretical plot shown
in Fig. S4(b) right panel. The upper Dirac cone extends upto $\sim$750 meV
above the Fermi level. Photon energy dependent dispersion maps along the high
symmetry directions are presented in Fig. S5. It suggests that a surface state
is seen at the $\bar{M}$ point (see Fig. S5(c)). We present second
derivatives, momentum distribution curves ( MDCs), Energy distribution curves
( EDCs) of dispersion maps along the high symmetry directions in Fig. S6 which
provide the visualization of the bands in the respective directions.

Supplementary Note 4: Anisotropic Dirac cones
As seen in the main text, the Fermi velocity varies on the direction with
respect to the $\bar{K}$-$\bar{M}$-$\bar{K}$ direction. Here, we show how
Fermi velocities vary when they make angles of 60∘ and 30 ∘ with respect to
the $\bar{K}$-$\bar{M}$-$\bar{K}$ direction (see Fig. S7). We take different
$\bar{M}$ points and show how the dispersion maps evolve with the angles. The
slopes of each dispersion map that makes 60∘-angles with
$\bar{K}$-$\bar{M}$-$\bar{K}$ should have the same magnitude, however, matrix
elements effects change the value to some extent. Nevertheless, anisotropic
behaviors are clearly seen.

Supplementary Note 5: Observation of Dirac node-arc
Observation of Dirac node-arc is presented in Fig. S8; we take 7 cuts in equal
intervals perpendicular to the $\bar{\Gamma}$-$\bar{M}$ direction. Figure
S8(b) shows the evidence of Dirac node-arc as all the dispersion maps show
Dirac dispersions. The Dirac node-arc extends over more than 1 $\AA^{-1}$ in
the $k$-space.

Supplementary Note 6: Electronic structures of Hf2Te2P and Zr2Te2P
In order to investigate the electronic structures of sister compounds of
Ti2Te2P, we present electronic structures of Hf2Te2P and Zr2Te2P and compare
them with Ti2Te2P in Figs. S9-S11. ARPES spectra show similar Fermi maps,
however, they are topologically different as a consequence of spin-orbit
coupling strength. Furthermore, Dirac points are located at different binding
energies. In Fig. S9, the Fermi map and dispersion maps along high symmetry
direction are presented. Even though many features are similar to Ti2Te2P,
some distinct features are seen in Hf2Te2P (for detail see Ref. [8]). Figure
S10 displays ARPES measured electronic structures of Zr2Te2P, it also shows
similar Fermi map however dispersion maps show somewhat different bands.
Figures S11 show experimental dispersion maps along the high symmetry
directions which illustrate the differences among these sister compounds.

Supplementary Note 7: $\mathbb{Z}_{2}$ indices calculations
In order to understand the topology of Ti2Te2P, we calculate $\mathbb{Z}_{2}$
indices for different bands as shown in Fig. S12 and tabulate in the table I.
The bands show different topological properties. Band 5 provides the topology
of the experimentally observed surface Dirac cone at the $\bar{M}$ (bulk F
point) point which shows the evidence of strong TI. Similarly, Fig. S13 (and
table II) displays the $\mathbb{Z}_{2}$ indices of Hf2Te2P. Therefore, one can
conclude Ti2Te2P is topologically different from Hf2Te2P.

Element |  Wt% |  At%
---|---|---
PK |  07.99 |  19.97
TeL |  68.08 |  41.33
TiK |  23.93 |  38.70
Matrix |  correction |  ZAF

Figure 1:  Energy dispersive X-ray (EDX) spectroscopy analysis of Ti2Te2P.
Figure 2: Resistivity plot of Ti2Te2P. Temperature variation of the electrical
resistivity measured with electric current flowing within the hexagonal plane
of the crystal. The inset shows the low temperature resistivity data. Figure
3: Photon energy dependent Fermi surface. (a)-(d) Photon energy dependent
Fermi surface map. The measurement shown in (a) was performed at the ALS
beamline 4.0.3 at a temperature of 16 K and (b)-(d) were performed at ALS
beamline 10.0.1. Figure 4: Dispersion maps along the different high symmetry
axes. (a)-(b) Band dispersions along the high symmetry directions as indicated
on the top of the plots. Right panel plots are calculated slab calculations of
corresponding left plots.

Figure 5: Photon energy dependent measurements along the high-symmetry
directions. Photon energy dependent band dispersion along the (a)
$\bar{M}$-$\bar{\Gamma}$-$\bar{M}$, (b) $\bar{K}$-$\bar{\Gamma}$-$\bar{K}$,
and (d) $\bar{K}$-$\bar{M}$-$\bar{K}$ directions, respectively. Photon
energies are labeled on the top of each plot. Measurements of dispersion maps
shown in (a)-(b) and rightmost plot of panel (c) were performed at ALS
beamline 4.0.3 at a temperature of 18 K, and first three left plots of the
panel c were performed at the ALS beamline 10.0.1.

Figure 6: Dispersion maps along high-symmetry directions, respective second
derivative plots, MDCs and EDCs. (a) Energy dispersion map, second derivative
plot, MDC and EDC for the dispersion map along the (a)
$\bar{M}$-$\bar{\Gamma}$-$\bar{M}$, (b) $\bar{K}$-$\bar{\Gamma}$-$\bar{K}$,
and (c) $\bar{K}$-$\bar{M}$-$\bar{K}$ direction, respectively. Measurements
were performed at ALS beamline 4.0.3 at a temperature of 16 K at a photon
energy of 100 eV.

Figure 7: Observation of anisotropic Dirac cone at the $\bar{M}$ point. (a)
Fermi surface maps at a photon energy of 90 eV. Lines indicated by numbers
represent the cut directions making angles of 60∘ and 30∘ alternately with the
$\bar{K}$-$\bar{M}$-$\bar{K}$ directions at different M points in the
Brillouin zone. (b) Dispersion maps for the cuts indicated on (a).
Measurements were performed in ALS beamline 4.0.3 at a temperature of 16 K at
a photon energy of 100 eV.  Figure 8: Observation of node arc along the
$\bar{\Gamma}$-$\bar{M}$ direction. (a) Constant energy contour at a binding
energy of 750 meV. Dotted lines show the cut directions. (b) Cuts are taken
perpendicular to $\bar{\Gamma}$-$\bar{M}$-$\bar{\Gamma}$ direction as shown in
(a). Measurements were performed in ALS beamline 4.0.3 at a temperature of 16
K at a photon energy of 100 eV.

Figure 9: Fermi surface and dispersion maps along the high-symmetry directions
in Hf2Te2P. (a) Fermi surface maps measured at a photon energy of 90 eV. (b)
Calculated Fermi surface. Dispersion maps measured along the (c)
$\bar{M}$-$\bar{\Gamma}$-$\bar{M}$, (d) $\bar{K}$-$\bar{\Gamma}$-$\bar{K}$,
(e) $\bar{K}$-$\bar{M}$-$\bar{K}$ directions, respectively. Data were
collected at the SIS-HRPES end station at the SLS, PSI at a temperature of 18
K.

Figure 10: Fermi surface and dispersion maps along the high-symmetry
directions in Zr2Te2P. Fermi surface map and dispersion maps measured along
the $\bar{M}$-$\bar{\Gamma}$, $\bar{K}$-$\bar{\Gamma}$ and
$\bar{K}$-$\bar{M}$-$\bar{K}$ direction at a photon energy of (a) 21 eV and
(b) 40 eV. Data were collected at the Laboratory for Advanced Spectroscopic
Characterization of Quantum Materials (LASCQM), UCF at a temperature of 20 K.
Figure 11: Measured electronic band structures of Ti2Te2P, Hf2Te2P and
Zr2Te2P. Dispersion maps along the high-symmetry directions are shown in (a)
for Ti2Te2P, (b) Hf2Te2P and (c) Zr2Te2P, respectively.

Figure 12:  Parities of bands at TRIM points in Ti2Te2P. Even (odd) parity is labeled + (-). Six bands are taken for the $\mathbb{Z}_{2}$ calculations. Band |  Z2 invariants |  $\widetilde{\Gamma}$ |  $\widetilde{M}$
---|---|---|---
1 |  (1;000) |  ✓ |
2 |  (1;000) |  ✓ |
3 |  (0;111) |  |
4 |  (0;111) |  |
5 |  (1;000) |  |  ✓
6 |  trivial |  |
Table 1: Calculations of $\mathbb{Z}_{2}$ indices in Ti2Te2P.

Figure 13:  Parities of bands at TRIM points in Hf2Te2P. Even (odd) parity is labeled + (-). Eight bands are taken for calculations. Band |  Z2 invariants |  $\widetilde{\Gamma}$ |  $\widetilde{M}$
---|---|---|---
1 |  (1;000) |  ✓ |
2 |  Trivial |  |
3 |  (1;111) |  ✓ |  ✓
4 |  (0;111) |  |  ✓
5 |  (0;111) |  ✓ |  ✓
6 |  (1;111) |  |  ✓
7 |  Trivial |  |
8 |  (0;111) |  |  ✓
Table 2: Calculations of $\mathbb{Z}_{2}$ indices in Hf2Te2P.

## References

  * [1] F. Philipp, P. Schmidt, M. Ruck, W. Schnelle, and A. Isaeva, J. Solid State Chem. $\mathbf{181}$, 2859 (2008).
  * [2] J. S. Oh, H.-S. Yu, C.-J. Kang, S. Sinn, M. Han, Y. J. Chang, B.-G. Park, K. Lee, B. I. Min, S. W. Kim, H.-D. Kim, and T. W., Chem. Mater. $\mathbf{28}$, 7570 (2016).
  * [3] G. Kresse and J. Furthmüller, Phys. Rev. B. 54, 11169–11186 (1996).
  * [4] G. Kresse, and J. Furthmüller, Comput. Mater. Sci. 6, 15–50 (1996).
  * [5] J. P. Perdew, K. Burke, and M. Ernzerhof, Phys. Rev. Lett. 77, 3865–3868 (1996).
  * [6] G. Kresse, and D. Joubert, Phys. Rev. B 59, 1758–1775 (1999).
  * [7] P. E. Blöchl, Phys. Rev. B 50, 17953–17979(1994).
  * [8] M. M. Hosen, K. Dimitri, A. K. Nandy, A. Aperis, R. Sankar, G. Dhakal, P. Maldonado, F. Kabir, C. Sims, F. Chou et al., Nat. Commun. 9, 3002 (2018).


# A multi-chain synchronization protocol that leverage zero knowledge proof to
minimize communication trust base.

Sinka Gao  Li Guo Qiang  Fu Hong Fei  Zhang Heng

###### Abstract

Delphinus Cross-Chain Aggregator is a universal firmware which synchronise
states between different smart contracts on different block-chains. In the
world of block-chains, synchronization challenges are two-folded. Firstly,
contracts from different main block-chain can not communicate with each other
which makes it hard to establish a trustworthy communication channel for them
to share and maintain a universal state between each other. Secondly,
transactions on different block-chains can hardly be ordered thus conflicts
are common and we need a novel way to avoid and handle these conflicts.
Delphinus Cross-Chain Aggregator is a ZKSNARK based multi-block-chain layer on
top of which rich cross chain applications can run safely and efficiently.

##  1 Introduction

As an emerging distributed computing paradigm, block-chain is rapidly evolving
in areas such as digital finance and cryptography. However, existing block-
chain projects adopt different block-chain architectures and protocols and, as
a consequence, it is difficult in general for different block-chain systems to
flow information to each other. Thus different block-chains themselves are
born isolated islands which brought limitations to the overall usability,
functionality and scalability of block-chain technology. [1]

Recently, the growing demand of flowing value between different chains
stimulates the demand of secure and consistent cross chain exchange protocols
for cross-chain communication and book-keeping. In order to address the
safety, liveness, permissionless and linearizability problem of various
protocols, and build trustworthy consensus between different block-chain
networks, cross-chain techniques received a lot of attention.

In general the difficult part of cross-chain communication is that there is no
proper way for a block-chain transaction to confirm whether a transaction was
executed successfully in another block-chain. This is because block-chain
system is a decentralized computing system that contains a large set of nodes
connected over a peer-to-peer network and a successful transaction needs to be
audited on multiple nodes, which means that a transaction’s result can only
depends on block-chain’s internal states otherwise the result of a transaction
will be inconsistent between different auditing nodes.

This builtin drawback of block-chain, makes it hard to execute a group of
transactions involving different chains so that either all of them or none of
them succeed on different chains. For example, suppose that Alice would like
to buy one token from Bob on block-chain A by spending one token on block-
chain B. To achieve this swap, two transactions $tx_{A}$ and $tx_{B}$ are
bundled:

  * •

$tx_{A}$: Alice get a token from Bob on block-chain $C_{A}$.

  * •

$tx_{B}$: Alice pay a token to Bob on block-chain $C_{B}$.

Moreover $tx_{A}$ and $tx_{B}$ need to be executed in a safe manner that
either both of them succeed or both of fail. If it is not the case, then
either Alice lose a token on block-chain B or Bob lose a token on block-chain
A. However since $tx_{A}$ can not access any info of $tx_{B}$, certain
protocol needs to be designed to achieve a safe swap.

Many protocols are developed in the literature including time hash lock,
interledger’s stream protocol, relay system, spv, side chain, etc and most of
them introduce a relayer to establish an information channel from source block
chain A to target block chain B as follows:

Figure 1: forward message using a relayer

The major security problems regarding the above model is that we require the
relayer to be honest and can be identified. A centralized relayer can be build
such that chain B only accepts info reported from a trusted relayer. In such
solution, the trusted relayer sign all their messages with their private key
and $tx_{B}$ in chain B checks signature accordingly. The problem of a
centralized relayer is that the relayer becomes one of the most important
trust base for the protocol to work which may leads to SIOF(single point of
failure) if relayer is hacked or misbehaved.

To take a step further, if we consider a protocol between Alice and Bob that
involves three transactions $tx_{A}^{0}$ on block-chain $C_{A}$, $tx_{B}^{1}$
on block-chain $C_{B}$ and $tx_{A}^{2}$ on block-chain $C_{A}$ in the
following order:

⬇

$s_{A}^{\prime}=tx_{A}^{0}(s_{A})$;

$s_{B}^{\prime}=tx_{B}^{1}(x,s_{B})$;

$s_{A}^{\prime\prime}=tx_{A}^{2}(y,s_{A}^{\prime})$;

Then it follows that the safety property require transactions involved in the
above bundle to be either all succeed or none of them succeed. Suppose a
protocal is designed to help carrying out such bundled transactions between
block-chains then we can define the safety, permissionless, liveness and
linearizability properties of the protocol as follows:

  1. 1.

permissionless: Every nodes of certain block-chain are allowed to join the
communication network.

  2. 2.

safety: All state updates for a single transaction are either successful or
fail on all involved block-chains.

  3. 3.

liveness: All valid transaction will eventually success on all block-chains

  4. 4.

linearizability: All parallel successful transactions is always linearlizable
so that the consequent state of a group of parallel transactions $tx_{i}$ is
equivalent to performing the transactions sequentially in a special order that
respects the happen-before relation of the original order.

###  1.1 Preliminary

While there are many existing protocols designed for specific scenarios and
they focus on preserving different properties with various trust base.
Delphinus Cross-Chain Aggregator targets to achieve liveness, safety,
permissionless and linearizability properties by using zero knowledge proof to
provide a universal layer to synchronise states between different smart
contracts on different block-chains and this layer together with its
communication protocol can be used as a cross-chain communication framework.
Below we will first clarify a few key definitions in our protocol and then
describe the main idea behind Delphinus Cross-Chain Aggregator .

####  1.1.1 Block-chain

A block-chain is a distributed database that is shared among network of
distributed nodes[6]. As a database, transactions are first submitted and
organized in blocks, while each block is a data structure that records the
most recent transactions which are not yet validated. Once a block was
validated the state of the whole distributed database is updated accordingly.

We use $C$ to denote a particular block-chain system with distributed nodes
storing data of $C$ in a distributed way. As the state of block-chain $C$ is
updated base on the validation of blocks, the observable state of a block-
chain can be abstracted as a state sequence. We use $S_{k}$ to denote the
whole state of a block-chain $C_{k}$ and $s_{k}$ to denote a partial state of
$S_{k}$.

####  1.1.2 Bundled cross-chain transaction

Given a group of block-chain $\left\\{C_{1},C_{2},\cdots,C_{k}\right\\}$, we
say a transaction $tx$ is a bundled cross-chain transaction if it is composed
of a sequence of transactions $tx_{k_{0}}^{0}$, $tx_{k_{1}}^{1}$, $\cdots$
$tx_{k_{j}}^{j}$ such that $j$th involved sub-transaction $tx_{k_{j}}^{j}$ is
supposed to be executed on $C_{k_{j}}$ locally and the behavior of each
$tx_{k_{j}}^{j}$ depends on state $s_{k_{j}}$.

In a bundled transaction $tx$, each local transaction $tx_{k}^{j}$ is executed
on the partial state of $s_{k}$. We use $s=\langle
s_{1},s_{2},\cdots,s_{k}\rangle$ to denote the underlying global state of $tx$
and we use $s_{k}$ to denote the projection of $s$ on block-chain $C_{k}$. For
example, a bundled transaction could looks like the following.

⬇

tx(s) {

$s^{1}=\langle tx_{0}(s_{0}^{0}),s_{1}^{0},s_{2}^{0},\cdots\rangle$

$s^{2}=\langle s_{0}^{1},tx_{1}(s_{1}^{1}),s_{2}^{1},\cdots\rangle$

….

$s^{n}=\langle s_{0}^{n-1},s_{1}^{n-1},s_{2}^{n-1},tx_{n}(s_{k}^{n-1})\rangle$

}

where $tx_{0}$ is performed on local state $s_{0}$, $tx_{1}$ is performed on
local state $s_{1}$ …, and the global state $s$ is changed to $s^{n}$ after
$tx$ is fully performed.

####  1.1.3 Aggregator Chain

In this work, we will introduce an extra block-chain to store the global state
$s$. We denote this chain as an aggregator chain to distinguish between it
from other block-chains $C_{k}$ involved in a bundled cross-chain transaction
$tx$. Also we will use native-chain as an abbreviation of $C_{k}$ to
distinguish them from our aggregator chain.

####  1.1.4 Merkely Tree Encoding of Global State.

Merkle[2] tree is a tree in which every leaf node is labelled with the
cryptographic hash of a data block, and every non-leaf node is labelled with
the cryptographic hash of the labels of its child nodes. Each data block has a
unique Merkle tree index(MTI) and each MTI encodes a unique path from top to
leaf.

Figure 2: merkle tree structure

####  1.1.5 State pinning.

State Pinning[9] is defined as including the state of one block-chain in
another block-chain. In our scenario, we denote $h_{k}$ pins the state $s_{k}$
if $h_{k}$ is generated from a collision-resistant hash of $s_{k}$.

####  1.1.6 Side effect.

We denote the changes of $tx_{i}^{k}$ on chain-state $C_{k}$ other than the
partial state $s_{k}$ to be the side effect $e_{k}$ of of $tx_{i}^{k}$. Side-
effects can be emitting events on native chains or native chain contract
calls.

####  1.1.7 Polynomial Commitment schemes.

Polynomial commitment schemes (PCS) provides the ability to commit to a
polynomial over a finite field and prove its evaluation at points[4]. A
succinct PCS has commitment and evaluation proof size sublinear in the degree
of the polynomial. An efficient PCS has sublinear proof verification. Any
efficient and succinct PCS can be used to construct a SNARK with similar
security and efficiency characteristics (in the random oracle model).

####  1.1.8 Zero knowledge proof of program execution.

Since PCS provides a scheme to prove evaluation of polynomials at certain
points, we can convert program evaluation into polynomials equations so that
the problem of proving program has certain results can be converted into
problems of polynomial equations. Further more, a zero knowledge proof of a
program execution is a PCS proof that can be used by a prover to convince a
verifier that a program is executed correctly with out leak any private
information.

The main idea of our protocol is to introduce a new chain (we will call it
aggregator chain below) so that instead of executing transactions in a special
order in a bunch of native block chains we do the following (see figure 3):

Figure 3: main idea of Delphinus Cross-Chain Aggregator

  1. 1.

We map local state $s_{i}$ of each block chain $C_{i}$ into our newly
introduced aggregator chain to form a global state $s=\langle
s_{0},s_{1},\cdots\rangle$.

  2. 2.

We perform a simulating run of the bundled transactions over $s$ on aggregator
chain to get a result state $s^{\prime}=\langle s_{0},s_{1},\cdots\rangle$ and
create zero knowledge proofs to convince native chain $C_{i}$ that after the
bundled transaction has been executed, their local state has to be changed to
$s_{i}^{\prime}$.

  3. 3.

We ask native chain $C_{i}$ to change their local state by providing them the
result state $s_{i}^{\prime}$ and the zero knowledge proof.

Before elaborating more details of our solution, we would like to give a brief
overview about a few existing cross-chain communication protocols and discuss
their safety, permissionless, liveness, and linearization properties.

###  1.2 Related Protocol Overview

####  1.2.1 Notary schemes:

The main idea of notary schemes is to elect one or more trusted nodes as
notary public and report transactions in different block-chain networks
through notaries[8]. Therefore all information transferred between different
block-chains are completely managed by notaries.

The centralized notary schemes is its efficiency in procession events and
simplicity in implementation. However it suffers with single point of failure
problem. Therefore, a multi-sig notary scheme may been proposed in order to
reduce the trust on certain centralized node. However, this multi-sig notary
are surely non-permissionless and needs extra protocols to ensure liveness.

####  1.2.2 SPV: Simplified payment verification

SPV is a special case of one direction state pining. In such protocals, block
header of A and a merkle proof of a particular transaction was monitored and
sent to target block-chain B. block-chain B accept the transaction trough
calculating the partial merkle tree hash and compare it with the block header
of block-chain A. The liveness properties of this approach depends on the
liveness of monitors of A and the safety property relies on the blockheaders
are reported to B honestly.

####  1.2.3 Sidechains:

The concept of sidechains was first proposed in 2014, main goal of sidechain
is to extend the scalability and functionality of the block-chain system. When
using sidechain as an trusted centralized entity in a 2-way peg system, it can
be used as a standalone transaction dealer. Sidechain can enforce the security
of transactions on itself by by implementing a protocol which can be validated
by consensus. Since the sidechain needs to update state changes back to the
underlying block-chains, the block-chains needs to trust or verify the
transactions sent out by sidechains. The safety property again relies on
whether observation of source chain can be honestly reported to the side chain
and whether the verifier on target chain can reject all fraud transactions. In
addition, since side-chain can suffer from deny-of-service attacks that leads
to a bundled transaction can not be finalized, the safety property also relies
on the liveness property.

Liveness of communication based on sidechains relies on how robust the
sidechain itself is and whether all the transactions happened on side chain
will get reported to the target chain eventually. Some improving ideas are
given in Plasma: Scalable Autonomous Smart Contracts for some improved ideas
of sidechains.

####  1.2.4 Two way peg:

A 2-way peg (2WP) works like a two way SPV which allows the transfer of assets
from one block-chain to another and vice-versa. The assets are technically not
transferred, but temporarily locked on the source block-chain while the same
amount of equivalent tokens are released in the target block-chain. The
transferred asset can be withdraw when the equivalent amount of tokens on the
target block-chain are locked again. The problem with this scheme is that the
transfer is not finished until the target block-chain has release the
equivalent amount asset. Therefore any 2WP system must do compromises and rely
on assumptions about the honesty of the actors involved in the 2WP.

####  1.2.5 Cross Chain Gateway and relayers:

Cross Chain Gateway with relays is another extension of the idea of state
pinning. While it enables block-chain interoperability applications including
cross chain token transfer, the safety properties are got at the cost of
storing every single block header of the source block-chain[3]. In general the
cost of storing such state is very expensive.

In conclusion we have the following table:

Protocal | Liveness | Safety | Permissionless
---|---|---|---
Notary schemes | yes | yes | no
SPV | conditional | conditional | no
Peg | conditional | conditional | no
SideChain | yes | conditional | yes
Gateway | yes | yes but costy | no

Delphinus Cross-Chain Aggregator derives the basic ideas from multi-way
sidechain (multiple block-chains with a shared sidechain) and solves the
trustworthy problem of the third parties by verifying the computation from
sidechain via zksnark proofs. In Delphinus Cross-Chain Aggregator , we denote
our specific sidechain as aggregator chain and involved block-chains of
bundled transactions as native chains.

Below We will present the brief picture of our solution by a case study of the
standard transfer and explain how zero knowledge is applied so that the
safety, liveness, permissionless properties hold. In Chapter 2 we describe
each components in details and then we explain the trust base of our solution
and prove that under the trust base our solution has full guarantee of safety,
permissionless and liveness properties in Chapter 3 and 4. In chapter 5 we
show that our solution has a linearization property.

Moreover, since our permissionless properties relies on a BFT consensus
algorithm which assumes that two thirds of the nodes of the aggregator chain
are honest, we present a potential incentive strategy to keep enough
decentralized nodes so that 2/3 majority attach is hard enough.

##  2 A case study of cross chain transfer

As a case study, we focus on a standard simplified asset transfer process from
Alice on chain A to Bob on chain B through a liquid provider.

###  2.1 State abstraction

Firstly we define the native-chain set in the bundled transfer transaction to
be $\mathbb{C}=\left\\{C_{A},C_{B}\right\\}$. As Alice has some asset on
$C_{A}$ and Bob has some asset on $C_{B}$ and a liquid provide has asset both
on $C_{A}$ and $C_{B}$, we can abstract our local state $s_{A}$ of $C_{A}$ and
$s_{B}$ of $C_{B}$ separately as follows.

⬇

1$s_{A}$ = state {

2 alice: number

3 lp: number

4}

5$s_{B}$ = state {

6 bob: number

7 lp: number

8}

Now, as we described in section 1.1, the underlying global state $s$ of
transfer is a tuple of $C_{A}$ and $C_{B}$:

⬇

1s = state {

2 sa: $s_{A}$,

3 sb: $s_{B}$

4}

Secondly the bundled transfer transaction $tx$ can be defined as a function on
global state $s$ as follows:

⬇

1function transfer(amount) {

2 token1.transfer(Alice, amount, lp);

3

4 ca.alice = ca.alice - amount;

5 ca.lp = ca.lp + amount;

6

7 cb.bob = cb.bob + amount;

8 cb.lp -= amount;

9

10 if(cb.lp > amount) {

11 token1.transfer(lp, amount, Bob);

12 }

13}

where line 2 can be treated as the invoke transaction on $C_{A}$, line 4-12
are bundled transactions that will be simulated on aggregator layer and line
11 is the side effect on $C_{B}$.

Now, to execute the transaction safely we fit this transaction into Delphinus
Cross-Chain Aggregator and divide the life cycle of the transfer into four
stages: consensus stage, operating state, proving stage and finalizing stage.

Figure 4: case study of a cross chain token transfer

  1. 1.

Consensus Stage: User Alice transfer a certain amount of money into a proxy
contract (line 2). After the contract handles the invoke transaction, it
commits the amount into its table of unfinalized invoke transactions and emit
a event. This emitted event will get monitored by Delphinus Aggregator Node
and triggers the consensus stage.

In the consensus stage, a voted node will encoded the consensus algorithm so
that it can prove (by ZKP) later to native chains that this invoke transaction
was honestly monitored by at least two-thirds of the Delphinus Aggregator
Nodes.

Also, Alice are allowed to withdraw unfinalized amount after a certain amount
of time(based on blockheight) (see chapter 2 for more information about
encoding consensus into ZKP circuits).

Invoke transaction are handled in this way because we need to make sure that
if the transaction fails(at simulation stage and proving stage) then the whole
transaction can be reverted by inverting the invoking transaction.

  2. 2.

Simulating stage: Once a transaction is ready to execute, it will be simulated
by the voted aggregator chain node so that a new resulting global state $s$
can be calculated and by projecting $s$ on to different partial state, we know
how to update the local state $s_{A}$ and $s_{B}$ on $C_{A}$ and $C_{B}$
accordingly.

  3. 3.

Proving stage: After Delphinus aggregator node finishes simulating the
execution of our particular transfer transaction, it will create a zero
knowledge proof to show that how to update all the partial state on $C_{A}$
and $C_{B}$.

Comparing to traditional side-chain solutions, who require audit nodes to
validate transactions and may suffer from majority attacks, Delphinus Cross-
Chain Aggregator uses ZKP to enforce that the simulation is carries out on
predefined functions (in this case, line 4-12 in transfer transaction). Thus
even the majority of the audit nodes are hacked, they can only perform attacks
that leads to deny-of-service of some of the transactions. Later in Chapter 4
we will prove that the DOS attack is also hard once we have a permissionless
aggregator chain and providing ZKP(zero knowledge proof) for consensus
algorithm as well.

Once the $tx$ was fully performed, aggregator chain will broadcasting this
transaction together with its proof to native-chain $C_{A}$ and $C_{B}$.

  4. 4.

Finalizing Stage: After a zero knowledge proof our a simulation of our
transfer is generated, the voted aggregator node will call a special finalize
contract on native block-chain $C_{A}$ and $C_{B}$ which will verify the proof
and then perform the side-effects of each sub transactions accordingly.

In the case of transfer, after the proof was verified, $C_{A}$ and $C_{B}$
will change their local state accordingly and on $C_{B}$, side effect (line
11) was performed so that Bob receives the transferred assert correctly(This
amount must equal to the amount transferred by Alice other wise the zero
knowledge proof will not be valid).

###  2.2 How zero knowledge proof technique is applied

For correctness, the ZK verification on verify contract makes sure that all
transactions are performed under predefined functions and the resulting state
are correctly calculated (merkle root hash is pinned). The pinned amount makes
sure that the custody of transferred tokens is reported to aggregator chain
honestly and the transfer on $C_{B}$ is performed at end which makes sure that
the amount about to withdraw is a consequence of valid transaction simulation.

###  2.3 Cost of zero knowledge proof verification

Regarding the cost problem of state pinning, since Delphinus Cross-Chain
Aggregator uses batched transactions to reduce the cost of signature check and
snark proof check, the problems of the high cost of state pinning and
signature check can be reduced to a acceptable level.

##  3 Protocol Details

The target of Delphinus Cross-Chain Aggregator is to provide a universal layer
to simulate and synchronise the global state between various block-chains
which support smart contract. This universal layer is organized as a block-
chain of Delphinus aggregator nodes and each node contains four abstract
components: storage component, transaction handler and simulator, native chain
relayer and transaction finalizer. Besides aggregator nodes, we also need to
install native proxy contracts on native block-chains so that they can invoke
transactions and update local state accordingly.

###  3.1 Delphinus aggregator chain node

As an example, suppose that we have two block-chains $C_{A}$ and $C_{B}$,
then, to perform cross chain transactions between $C_{A}$ and $C_{B}$, our
single Delphinus Cross-Chain Aggregator involves the following entities
(figure 5).

Figure 5: protocol components

with each components performs the following functionalities:

  * •

a proxy smart contract $\mathcal{A}$ on $C_{A}$ (Trusted).

  * •

a proxy smart contract $\mathcal{B}$ on $C_{B}$ (Trusted).

  * •

a transaction handler that handles and simulates transactions.

  * •

a storage component that tracks the global state.

  * •

a relayer $\mathcal{R}_{A}$ to monitor invoke(revoke) transaction events for
$\mathcal{C}_{A}$ and reports them to transaction handler.

  * •

a relayer $\mathcal{R}_{B}$ to monitor invoke(revoke) transaction events for
$\mathcal{C}_{B}$.

  * •

a finalizer that communicates with proxy contracts to finalize transactions.

  * •

a data storage component that tracks the global state.

Moreover, in a block-chain setting, we combine the finalizer, storage
component, transaction handler and relayer (which are everything except proxy
contract on native block-chain) together with an extra consensus component
into a Delphinus aggregator chain node. These distributed Delphinus aggregator
node forms a block chain that works together to synchronize and alter states
between guest block chains and each components in node performs the following
task:

  1. 1.

chain storage component:

     * •

store the global state.

     * •

store the merkle root hash of the whole state.

     * •

store the valid voter list and the merkle root hash of all voters.

  2. 2.

transaction handler and simulator.

     * •

order aggregator chain transactions under certain consensus.

     * •

process transactions and update the whole state accordingly.

     * •

emit transaction events (with execution order).

  3. 3.

native chain relayers:

     * •

handle event emitted by invoke transaction of a bundled transaction.

     * •

handle event emitted by revoke.

  4. 4.

transaction finalizer:

     * •

calculating transaction execution proofs.

     * •

calculating proofs of consensus.

     * •

submit proofs to guest chain for validation and finalize.

  5. 5.

consensus component:

     * •

performing consensus algorithm (voting block generator).

     * •

calculate ZKP of consensus algorithm.

     * •

generate and prepare block.

Last but not least, proxy contract on native-chain is also an important
component of Delphinus Cross-Chain Aggregator as it is used to maintain the
partial state of a particular native-chain by performing proof verification,
state updating and processing the sideffects of each transactions during the
finalize stage.

###  3.2 Transaction lifecycle

A bundled cross-chain transaction $tx$ in Delphinus aggregator node is a
composed set of operations $tx_{i}^{k}:s_{k}\rightarrow s_{k}$. By defining
how the local state $s_{k}$ of the application can be changed through
$tx_{i}^{k}$, $tx$ can be treated as a function based on the global state $s$.
In Delphinus Cross-Chain Aggregator the global state of an application is
compressed as a Merkle hash tree and pinned in all the guest chain proxy
contracts.

For a transaction to be successfully executed in Delphinus Cross-Chain
Aggregator , it experience four stages: Consensus Stage, Operating Stage,
Proving Stage and Finalizing Stage (see figure 6).

Figure 6: transaction life cycle

  * •

Consensus Stage: As a decentralized protocol, a transaction will not get
handled until it is collected in a block. Each blocked is produced by an
elected node under a pre-defined consensus algorithm (see 3.2). A node who
wins the consensus game needs to provide a zk proof which will later be used
as evidence to finalize all transactions within the block on guest proxy
contract.

  * •

Operating Stage: At operating stage, an operation is simulated on Delphinus
aggregator chain and changes the global state (S) thus changes the Merkle root
in a sandbox. During the simulation, all the witness needed to create a zkp
for it is prepared and stored. Since all transactions are handled sequentially
regarding their order in a particular block, their witness are stored in the
same order so that they can be batched in the proving stage.

  * •

Proving Stage: After operating stage, the Delphinus aggregator chain relay
will generate all the proofs for every transaction and compress proofs into a
single zkp proof. This proof is then appended after the transaction arguments
in the block with a updated merkle tree hash.

  * •

Finalizing Stage: Once a proof of batched operation sequence is generated by
Delphinus aggregator chain monitor, it will broadcast to various underlying
block-chains. The block-chain needs verify the proof and then send acknowledge
back to the Delphinus aggregator chain to finalize the transaction.

####  3.2.1 Consensus Stage

A consensus algorithm is a common process in block-chain to achieve agreement
on value or state among distributed nodes. A consensus algorithm is critical
in safety in systems that contain permissionless unreliable nodes. In
Delphinus Cross-Chain Aggregator we need consensus algorithm to solve the
following problem:

  1. 1.

Who can decide the order of the bundled cross-chain transactions.

  2. 2.

How to enroll and identify a valid node.

  3. 3.

Who can produce the next block and finalize the transactions in it.

In Delphinus Cross-Chain Aggregator we uses a modified PBFT[5] consensus
algorithm between chain nodes to vote for a block generator. Recall that PBFT
consensus consists of three phases: Pre-Prepare, Prepare, and Commit. At Pre-
Prepare stage, the primary node is responsible for verifying the requests and
generating corresponding pre-prepare messages. Then, the primary node will
broadcast pre-prepare messages to all Replica nodes. After receiving the
messages, Replica nodes will verify the legitimacy of those pre-prepare
messages and then broadcast a corresponding prepare message.

In Delphinus Cross-Chain Aggregator the final step is carried out on native
chains thus the results are not broadcast back to replica nodes but broadcast
to native chain nodes and verified there. Moreover, in addition to verifying
that the results are correctly calculated we also need to convince guest chain
that our generated block are produced under the consensus protocol as well.
Usually since the native-chain do not attending the consensus algorithm in
aggregator-chain, it has problems of checking whether the transaction results
are reported from a valid picked node. Thus we need to encode the consensus
algorithm and its result into a zero knowledge proof so that we can confirm
guest proxy contract that the blocked which contains all transactions is
generated legally. The consensus result together with its zkp proof is stored
in a new generated block as described as follows (Fig 7).

Figure 7: data layout of a aggregator block

Thus after consider the above requirements, we used a modified PBFT approach
which still consists of three phases but each phases is slightly modified as
described below.

Firstly, at pre-prepare stage a node need to be registered as a valid block
generating candidate and broadcast the ZKP of the validation to other nodes.
During the process of voting (prepare stage), each aggregator chain node in
consensus stage places a vote and send a signature of the vote to their voting
target. Suppose that two thirds of the nodes in the system are honest then it
follows that only one potential node will win the voting game and this
particular node has the authority to produce a block.

Secondly, after a certain node gathers enough voting messages, instead of
broadcasting the result, the winner node will calculate the ZKP(zero knowledge
proof) of our consensus algorithm and put it into its generated block. This
ZKP will later been used to convince native block-chain that a batched
transaction proof is send from a legally voted node. Once the proof is
attached in the newly generated block the winner node will start producing
transactions(see figure 8).

Figure 8: voting process during consensus

In the end, the winner node will broadcast the generated block to native
block-chains and Delphinus Cross-Chain Aggregator proxy contract on native
block-chain will verify and finalize this block and update their local state
accordingly.

In addition to produce zkp for consensus algorithm, Delphinus Cross-Chain
Aggregator also targets to build a permissionless chain that every one can
join the aggregator chain to helping synchronizing bundled cross-chain
transactions. This means we need to provide a protocol to register and remove
a valid voter. To achieve that, Delphinus Cross-Chain Aggregator keeps a
merkle tree of all valid nodes by tracking their public keys as merkle tree
data nodes and any one can register to be a valid node by registering itself
as a new merkle tree leaf. Also, for a aggregator node to vote for the next
block producer, it has to prove he is a valid merkle tree node thus a
registered valid node first and then sign and send his voting ticket to the
voted node. More precisely anyone can do the following:

  1. 1.

Register a node for voting: Node registration is a aggregator chain
transaction that updates the merkle tree of all valid voters on aggregator
chain and has side effect of updating the merkle tree root hash of nodes in
guest proxy contract. It is every aggregator node’s responsibility to keep the
registration tree updated so that the root hash are consistent with the pinned
hash in the proxy contract.

  2. 2.

Valid a voter: When a node receive a voting from other node, it needs to
validate that the sender is a valid voter. If the sender is an invalid node
(eg, a malformed node without registration in) then proof of sufficent voter
will fail at the stage of finalize thus waste the computing source of the node
who is voted.

Recall that all the valid voter is arranged in a merkle tree whose root hash
is pinned in the guest proxy contract. The voter needs to provide a identity
proof (in forms of zk proof) to show that his public key(or voting address) is
one of the merkle tree leaf nodes.

Once a node receive a voting from voter $V$, it needs to verify the identity
proof of $V$ first before it push it to the list of his supporters for next
block generation round.

  3. 3.

Send a valid vote ticket: A vote ticket contains two parts, a signature and a
validation proof. The signature is signed from the current block height
together with merkely root hash of all valid voters. The validationg proof is
a zero knowledge proof proves that the voter is one of the valid voters.

####  3.2.2 Simulation Stage

After a node is voted as a block generator, it can starting collecting
transactions from various sources. In Delphinus Cross-Chain Aggregator
transactions are submitted to aggregator node via three sources(fig
LABEL:simulation-stage).

1\. Pure bundled transaction that does not contains a invoking transaction: A
pure bundled transaction is supposed to be send directly to Delphinus Cross-
Chain Aggregator nodes and all its internal sub transactions should either all
succeed or fail. Also whether each sub transactions will succeed is decidable
via simulation in aggregator node so that the aggregator node can simulate the
result first and then finalize the state change on native block-chains.

2\. Bundled transaction that contains a invoking transaction: This kind of
bundled transaction likes the pure bundled transaction except that its first
sub transaction (and only the first sub transaction) can not be simulated by
aggregator node. When handling this kind of transaction, the first transaction
is executed on native-block chain first and the relayer of aggregator node
monitors the result of the first transaction. If the first transaction is
succeed, the relayer submits a following transaction to the aggregator node.
If not, the relayer submits a revoke transaction to the aggregator which will
trigger a revoke of the invoking transaction just performed on native-chain.

3\. System transactions: This kind of transactions are submitted by aggregator
nodes and it contains voting transaction, voter registration transaction,
voter quit transaction, etc.

####  3.2.3 Proving Stage

As we discussed before, we simulate bundled transactions of the global state
on aggregator chain node and each bundled transaction is equivalent to a
function $(f:state\rightarrow state)$ that alter and query the global state
$s$. Since the global state is pinned on native-chain by the merkle hash root
$h(s)$ of the state, a zero knowledge proof of bundled transactions $tx$ is a
proof that ensures the merkle hash root of the result state $s^{\prime}=f(s)$
is valid.

Figure 9: state refine of transaction circuit

For instance(see figure 9), suppose that, before the transaction, state $s$ is
encoded as $mht$ in a format of standard merkle tree which has root hash $r$
and after simulating the transaction the state changes to $s^{\prime}=f(s)$.
Also suppose that this new state was stored in the aggregator chain storage in
a format of updated merkle tree $mht^{\prime}$ whose new root hash is
$r^{\prime}$. Then it follows that we need to create a zero knowledge proof to
show that the following constraints holds.

$constraints=\begin{cases}r=root(mht(s))\\\
r^{\prime}=root(mht(s^{\prime}))\\\ mht(s^{\prime})=mht(f(s))\end{cases}$

where the first two constraints are constraints about the state before and
after the transaction and the last constraint is about the simulation of
function $f$.

Moreover, $f$ can be treated as a sequence of leaf update of the merkle tree
of state $s$. For each leaf update, suppose that
$P_{k}=[p_{0},p_{1},p_{2}\cdots p_{n}]$ is the MTI of an updated leaf of data
$D_{k}$. It follows that to calculate the root hash after the modification of
data of $D_{k}$, we need to calculate new hash root at each level from $p_{n}$
to $p_{0}$ by the formula

$H_{k}(p_{k})=hash(H(p_{k+1}^{0}),H(p_{k+1}^{1}),\cdots)$

where $a_{i}=p_{k+1}^{j}$ are nodes who have the same parent $p_{k}$ as
$p_{k+1}$[7]. A full transaction $tx$ is a data transform function $f$
performed on multiple Merle leaf nodes. In Delphinus aggregator node $f$ is
defined as a combination of the following:

  1. 1.

simple merkle tree leaf update.

  2. 2.

predefined functions that has predefined zkp circuits.

  3. 3.

crypto functions including signature functions and hash functions.

####  3.2.4 Finalizing Stage

We know that a bundled transaction $tx$ is a state transform over global state
$s$ and is composed of a sequence of sub transactions $tx^{j}_{k_{j}}$ on
$C_{k_{j}}$. During the finalizing stage, Delphinus Cross-Chain Aggregator
performing mainly two things. Firstly it checks the ZKP of the consensus
algorithm to make sure the block was generated by a valid block producer and
then it checks the ZKP of the simulation of $tx$ so that the proxy contract
can safely update the local state on $C_{k_{j}}$. Secondly the proxy contract
performs the side effects of $tx^{j}_{k_{j}}$ on $C_{k_{j}}$ (e.g., if a user
would like to withdraw some asset from aggregator chain to guest chain, then
during the finalize procedure a transfer from guest chain proxy contract to
the target account of the withdraw is executed).

###  3.3 Guest Proxy Contract

Guest Proxy Contract contains two parts: guest chain interface and
verification interface (fig 10). Both of them manipulates the guest chain
local state. Guest chain interface includes invoke and revoke which allows
guest chain user to invoke or revoke a message. Verification interface is
called by Delphinus cross chain node to finalize transactions.

Figure 10: local state of guest proxy contract

####  3.3.1 Guest chain interface

When a user invoke a guest chain interface, a transaction info with the
current block height ($h$) is recorded in the pending queue of the guest local
state. The user who performed invoke transaction can revoke his invocation any
time when the transaction remains in the pending queue after a fixed amount
($\delta_{h}$) of block. This means Delphinus cross chain nodes have to notice
and handle this event and finalize this event within $\delta_{h}$ blocks.

Figure 11: time window for finalizing a block

####  3.3.2 Verification Interface

Verification interface verifies the ZK-SNARK proof generated by the aggregator
chain node(see section 2.5).

    function verify(
      uint256 l2account,
      uint256[] memory tx_data,
      uint256[] memory verify_data, // zk proofs
      uint256 vid,
      uint256 nonce,
      uint256 rid
    )

Recall that only the winner of Delphinus voting consensus of the current
finalize round (rid) have the authority to invoke verification interface at
round $rid$. It follows that the verify function first check the voting proof
to ensure that the sender is the winner of round $rid$ and then check every
transaction encoded in tx_data is executed honestly via verify the zk proof
encoded in verify_data. If both check pass, guest contract will perform all
the side-effects of transactions on guest chain accordingly.

####  3.3.3 Transaction side effects during finalize

  * •

Invoke An invoke tx on aggregator chain must be related to a invocation call
on guest contract. Since every time a guest chain invocation will cause a
record of pending invocation to be added in to the pending list in the local
state of guest contract. Once a invoke tx is verified, the side effect of that
tx is removing the invocation record in the pending invocation list. Once a
invocation was removed from the pending invocation list, its sender lose the
capability to withdraw it.

  * •

Callback Callback is a special transaction that is invoked through Delphinus
Cross Chain Node which tries to trigger a certain callback function from
Delphinus Cross Chain to guest Chain. Once a callback tx was verified, its
side effect is to calling a relataed guest contract api according to the tx
info. Withdraw is a special case of callback which calles the trasfer api.

  * •

General Cross Chain Node Transaction:

    * –

All general cross chain node transactions are handled on Cross Chain Nodes
thus changes the cross chain state.

    * –

As the cross chain state is pinned to guest contract there is no other side-
effect during the process of finalization.

###  3.4 Guest Chain Relayer

Guest chain relay is responsible for monitor guest chain events and notify
aggregator chain tx handlers by forwarding them. Guest chain relay needs to
sign the event with CrossChain Node’s consensus id so that guest chain relay
from another CrossChain Node could not forward invoking transaction to other’s
aggregator chain transaction handlers. If a voted CrossChain Node failed to
finalize their transactions in guest chain prox contract, then it either
failes to calculate a correct aggregated proof of transactions and voting
result or it does not pass the checks in the side-effect of invoking
transactions in guest contract. In later case, the failed node could be a
malicious node who provides invoking transactions that does not exist on guest
chain.

Figure 12: perform side effects of a bundled transaction

###  3.5 Aggregate and broadcast multiple tx proofs

Each time Delphinus aggregator chain relayer captures a full block generated
by aggregator chain tx handler, it opens the block and generate a zk proof for
each transaction and then aggregate the consensus proof together with all
transaction proofs into one zk proof as the final proof of this block. After
the final proof is added into the block, Delphinus aggregator chain relayer
sends the final proof together with all the transactions contained in the
block to delphinus proxy contracts for finalize.

zero knowledge proof aggregation is a zkp technique that can aggregate a
sequence of proofs into one proof. The benifit of aggregating zk proofs is
that it can reduce the calculation workload of verification. Recall that our
aggregator chain relayer will generate a zk proof for each user transaction
and each zk proof ensures that a transaction $tx_{k}$ changes state from
$s_{k}$ to $s_{k+1}$ by proving that the root of merkely tree hash $H$ changes
from $hash(s_{k})$ to $hash(s_{k+1})$. An aggeregated proof batches all
transaction proofs and generate a proof ensures that by execution a sequence
of transaction $tx_{0},tx_{1},\cdots,tx_{n-1}$, the aggregator chain state
changes from $s_{0}$ to $s_{n}$.

Moreover, since the aggregator chain relayer needs to provide both the
consensus proof and the aggregated transaction proof, we can further batch
these two zk proofs into one.

##  4 Permissionless and Liveness property

Delphinus cross chain is a decentralized platform that any one can join the
network to help synchronizing cross chain bundled transactions. Thus to show
that Delphinus cross chain is a permissionless system, we need to show that
althought any running Delphinus cross chain node can play the role of
synchronizing cross chain transactions, the data stored in Delphinus cross
chain is consistent and all local data stored in distributed nodes converges.

###  4.1 Proof of voting result

Give a group of bundled transactions $\mathbb{B}=\left\\{btx_{i}\right\\}$
submitted simultaneously. A valid trace from a start point of global state $s$
is a sequence of state $s_{0}=s,s_{1},s_{2},\cdots s_{n}=s^{\prime}$ such that
$s_{k}=btx_{k}(s_{k-1})$ where $btx_{k}\in\mathbb{B}$.

It is obvious that different order of $btx_{k}$ from same $\mathbb{B}$ can
leads to different valid traces which means all attending nodes in the
Delphinus cross chain needs to vote for a unique block producer to generate a
trace that is valid globally.

Each round before voting, every attending node’s public key is registered in a
merkley tree and the root hash is pinned in all native chains and nodes. We
assume that each node will synchronize the root hash themselves before vote
since if they vote with a wrong root hash then their vote ticket is ignored
when producing the final zero knowledge proof of the voting result.

To vote a node, a voter needs to sign a voting message and send the signed
voting message to the target it votes. Inside the message it contains the
merkle root hash of all attendence. Once a node receives a sufficient number
of voting tickets that carry the correct attendence hash it will produce a
zeroknowledge proof $\mathbb{P}_{v}$ which shows that the total number of
tickets reachs two-thirds of the total number of voters and all of them has
the correct attendence hash.

###  4.2 Block generating

As mentioned in 3.3, after the winner node calculated the zkp proof of all
received signatures, it can start producing a block which represents a valid
sequence of bundled transactions $btx_{i}$. This process is executed locally
and the block producer can pick any order of $btx_{i}$ in the final sequence
as long as it can generate a zkp proof of the simulation $btx_{i}$

Figure 13: produce a block after voting

Once the block was generated, it needs to be send to the native block chain
$C_{i}$ to finalize before it can be recorded in the Delphinus aggregator
chain ledger. Since Delphinus nodes are permissionless, the liveness of the
whole system should not relay on the liveness of a particular node. Thus we
need to provide a protocal to make sure the winner node can not broadcast the
block partially. For example if the winner only broadcast the block to a
subset of the native block chains then we need a strategy to continue
broadcasting the block even if the winner node quit after generating the
block.

To solve the partial synchronize problem, we record the proof data on the
native local chain $C_{i}$ so that if a block was synchronized partially, then
all Delphinus node will notice the recorded proof and can continue
broadcasting the proof until it is fully synchronized.

Moreover, if the winner does not broadcast its block to any of the local
chains, then the voter need to trigger another vote to skip the current round
of block producing and send the skip signal to all native block chains. Once
all the native block received the skip signal, they will not accept any block
with the current round number and the next round of block generation can
start. If one of the native chain received the synchronizing call of the
generated block, then all the nodes need to perform a revoke-skip vote so that
they can revoke the skip signal on native block chains.

###  4.3 Liveness property

Based on protocol defined as above, we abstract the state transition diagram
as follows:

Figure 14: state transition

Notice that in the protocol, there exists state $S_{5}$ in which both the
block generation voting and skip voting are fired. If skip signal was fully
applied to all native chains then the current round was skipped otherwise if
any one of the native block chain receives the generated block, then our
protocol ensures that all the other nodes will receive the same generated
block as well. Thus the final state of all native-block chains converges to
the same state.

##  5 Safety property

Recall that for a bundled transaction $tx={tx_{i}^{k_{i}}}$. The safety
property of a protocol to carry out $tx$ is that either all $tx_{i}^{k_{i}}$
are succeed or none of them succeed.

We split the proof of safety property of Delphinus Cross-Chain Aggregator in
to three steps. Firstly, we show that the safety property holds if a
transaction $tx$ does not have an invoke transaction or any side-effects.
Secondly we further prove that if all side-effects are safe then the safety
property still holds. Finally we show that if the first transaction of a
bundled transaction $tx$ is an invoke transaction, then we can rely on our
liveness property to ensure that if the invoke transaction succeed then all
following transactions will eventually be finalized and if the invoke
transaction fail then it can be revoked using a revoke transaction so that the
global state stays the same.

###  5.1 Bundled Transaction with no invoke transaction

If a bundled transaction does not start with an invoke transaction, then it
means the bundled transaction is invoked directly on the aggregator chain.
Because all components $tx_{i}$ of $tx$ are simulated and performed on
aggregator chain and a proof of the execution of $tx$ can not been generated
if any $tx_{i}$ fails during the simulation, a transaction can only be
executed a whole. Once the ZKP proof was generated for the simulation, it will
be used to convince each native-chain to change their local state according to
the result of the simulation.

If the proof is valid, and is submitted to native chains then it will pass the
validation check and then we expect that the local state of the native chain
will changed accordingly with no exception. Since the liveness property
promises that all native chain will native eventually receive the valid proof,
it remains to show that the state updating protocol in our proxy contract is
safe.

A smart contract is a piece of code that can not been changed once deployed,
its behavior is fixed and predictable. Thus we can assume that our proxy
contract always perform correctly according to its pre-defined functionality.
Suppose that $s$ is the start global state, $tx$ is the transaction and
$s^{\prime}$ is the final state. When our proxy contract receives $MTH(s)$,
$tx$, $MTH(s^{\prime})$ and the state difference $\delta_{s}$ together with a
zero knowledge proof $p(MTH(s),MTH(s^{\prime}),tx)$, our proxy contract will
do the following:

  1. 1.

Proxy contract checks that pined local global hash equals $MTH(s)$. This makes
sure that the current local state $s_{i}$ is consistant with the global state
$s$.

  2. 2.

Proxy contract verifies the proof $p(s,s^{\prime},tx)$. Once the verify
succeed, it can guarantee that $s^{\prime}$ is a valid final state after
simulating $tx$ over $s$.

  3. 3.

Compute the changes of $s_{i}$ and change the local state from $s_{i}$ to
$(s_{i})^{\prime}$. Since updating local state is a monadic function of local
state, it will never fail which means once the proof of $tx$ is verified,
local state will be changed correctly for sure.

  4. 4.

Proxy contract performs all the related side effects for each transactions
$tx_{k}$ in bundled transaction $tx$.

We notice that step 4 is the only place that a finalizing call will fail even
the proof are correct. To address this problem, we break down side-effects
into two categories. The first category contains side effects like emit
events, logging or pure history recording which are naturally safe since it
will never fail by design. The second category includes unsafe function calls
like assets transfer. This kind of unsafe functions can still be safe if we
perform sanity checks in tx.

For example, if $tx_{k}$ in $tx$ will trigger a side-effect $e_{k}$ and
$e_{k}$ is safe under condition $P$ where $P$ is a predicate of global state
$s$, then we can insert a check after $tx_{k}$ as following:

    ...
    let s’ = tx_k(s);
    if !P_k(s’):
        raise Excepition(sainity check failure)
    let s’’ = tx_{k+1}(s);
    ...

Once $tx$ is modified so as above, a valid proof of a correct simulation of
$tx$ will ensure not only the final state are valid but all the sainity checks
are all valid and $e_{k}$ will be safe for sure.

###  5.2 Bundled Transaction with an inovke transaction

If a bundled transaction $tx$ starts with an invoke transaction $tx_{0}$ on
$C_{i}$, then this invoke transaction on chain $C_{i}$ triggers the execution
of the bundled transaction $tx$ by emit a invoking event. This event is
reported to aggregator chain through an native-chain relayer. The aggregator
chain bundled transaction simulator relies on the honesty of the reporter and
if the relayer is hacked it can exploit the protocol by reporting malformed
results of the inovke transaction. For example, in the transfer scenario, if a
report reports the wrong amount of asserts that been transferred from Alice to
Bob in Chain A then a successfully finalized $tx$ will trigger a wrong
transfer from Bob to Alice on Chain B.

To address this problem and make sure the protocol is safe even the relayer is
dishonest, we split the process of the changes of global state $s$ into two
stages. At first stage $s$ is changed to $s^{\prime}$ after invoke transaction
and at second stage $s^{\prime}$ is changed to $s^{\prime\prime}$ after the
whole simulation of $tx$.

During the first stage $s^{\prime}$ is pined in native chain $C_{i}$ once the
invoke transaction is executed and the second stage is encoded by a zero
knowledge proof generated from Delphinus aggregator chain node. During
finalize, proof of $tx$ now encodes the proof from $s^{\prime}$ to
$s^{\prime\prime}$. To ensure that the invoke transaction $tx_{0}$ is reported
correctly, the verifier only needs to compare the MTH of local calculation of
$s^{\prime}$ and the hash provided by the aggregator chain Node. If the hash
are the same, then it means $tx_{0}$ are reported honestly. More over since
$s^{\prime}$ are checked, $s^{\prime\prime}$ can be treated as a valid
simulation from $s$ to $s^{\prime\prime}$. In conclusion the finalization
steps are listed as follows:

  1. 1.

Proxy contract checks that pined local global hash equals
$MTH(s^{\prime\prime})$. This makes sure that the current local state
$s_{k}^{i}$ is consistant with the global state $s^{\prime}$ after processing
invoke transaction. Thus the invoke transaction are reported honestly.

  2. 2.

Proxy contract verifies the proof $p_{t}(s^{\prime},s^{\prime\prime},tx)$.
Once the verify succeed, it can guarantee that $s^{\prime\prime}$ is a valid
final state after simulating $tx$ over $s$.

  3. 3.

Compute the changes of $(s^{i})^{\prime}$ and change the local state from
$(s^{i})^{\prime}$ to $(s_{i})^{\prime\prime}$. Since updating local state is
a monadic function of local state, it will never fail which means once the
proof of $tx$ is verified, local state will be changed correctly for sure.

  4. 4.

Proxy contract performs all the related side effects for each transactions
$tx_{k}$ in bundled transaction $tx$.

##  6 Linearity property

In concurrent programming, an operation (or set of operations) is linearizable
if it consists of an ordered list of invocation and response events. In
Delphinus cross chain protocol, the linearity property holds trivially.
Because in each block generation round only one node wins the right to produce
a block, the linearity hold iff and only if the final state simulated in the
block can be represented as a sequence of bundled cross transactions
$btx_{i}$. Since each block producer needs to create a zero knowledge proof to
show that $s^{\prime}=btx_{k}\circ btx_{k-1}\circ\cdots btx_{0}(s)$, a valid
proof already shows the linearity property.

## References

  * [1] Ittai Anati, Shay Gueron, Simon Johnson, and Vincent Scarlata.  Innovative technology for cpu based attestation and sealing.  In Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy, volume 13. ACM New York, NY, USA, 2013.
  * [2] Georg Becker.  Merkle signature schemes, merkle trees and their cryptanalysis.  Ruhr-University Bochum, Tech. Rep, 12:19, 2008.
  * [3] Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, and Miguel Correia.  A survey on blockchain interoperability: Past, present, and future trends.  ACM Computing Surveys (CSUR), 54(8):1–41, 2021.
  * [4] Dan Boneh, Justin Drake, Ben Fisch, and Ariel Gabizon.  Halo infinite: Proof-carrying data from additive polynomial commitments.  In Annual International Cryptology Conference, pages 649–680. Springer, 2021.
  * [5] Miguel Castro, Barbara Liskov, et al.  Practical byzantine fault tolerance.  In OsDI, volume 99, pages 173–186, 1999.
  * [6] Wubing Chen, Zhiying Xu, Shuyu Shi, Yang Zhao, and Jun Zhao.  A survey of blockchain applications in different domains.  In Proceedings of the 2018 International Conference on Blockchain Technology and Application, pages 17–21, 2018.
  * [7] Moses Liskov.  Updatable zero-knowledge databases.  In International Conference on the Theory and Application of Cryptology and Information Security, pages 174–198. Springer, 2005.
  * [8] Kaihua Qin and Arthur Gervais.  An overview of blockchain scalability, interoperability and sustainability.  Hochschule Luzern Imperial College London Liquidity Network, 2018\.
  * [9] Peter Robinson and John Brainard.  Anonymous state pinning for private blockchains.  In 2019 18th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/13th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE), pages 827–834. IEEE, 2019.